Frank Denneman написал отличную статью о разделении NVIDIA Multi-Instance GPU (MIG) с учетом геометрий размещения и потерянных ёмкостей ресурсов.

Архитектура инфраструктуры ИИ

Предыдущие статьи в этой серии объясняли, как работает совместное использование GPU с разделением по времени как в средах вида same-size, так и со смешанными размерами. Они показали, что такие выборы, как профили и порядок запуска рабочих нагрузок, могут напрямую влиять на использование GPU и на то, будут ли рабочие нагрузки успешно размещены. В этой части мы рассматриваем MIG и решения по проектированию, которые влияют на успешность размещения и общее использование ресурсов.

MIG использует другой подход к совместному использованию GPU. Вместо мультиплексирования вычислительных ресурсов между рабочими нагрузками MIG разделяет GPU на аппаратные экземпляры. Каждый экземпляр получает собственные выделенные вычислительные срезы (slices) и срезы памяти.

Каждый экземпляр предоставляет три основные функции: изоляцию сбоев, индивидуальное планирование и отдельное адресное пространство. Когда требуется строгая аппаратная изоляция, MIG является правильным решением, потому что рабочие нагрузки не могут мешать друг другу, а потребление ресурсов становится предсказуемым.

Многие администраторы и операторы выбирают MIG как технологию для предоставления дробных GPU без строгого требования к жёсткой изоляции. Эта статья сосредоточена на таком сценарии использования и определяет проблемы успешного размещения и использования ресурсов, включая то, как выбор профиля напрямую определяет, будет ли ёмкость GPU полностью использована или навсегда останется потерянной.

Модель ресурсов MIG

В предыдущих статьях этой серии было показано, что ёмкость GPU определяется не только объёмом свободной памяти. Ёмкость зависит от того, как ресурсы разделены и размещены. MIG добавляет ещё один уровень ограничений размещения.

Все архитектуры GPU NVIDIA, поддерживающие MIG, включая Ampere, Hopper и Blackwell, имеют одинаковую структуру. Каждый GPU предоставляет семь вычислительных срезов и восемь срезов памяти. Профили используют оба ресурса одновременно, поэтому каждый профиль представляет собой определённую комбинацию вычислительных срезов и срезов памяти, соответствующую физической структуре GPU.

В этой статье в качестве примера используется GPU H100 с объёмом памяти 80 гигабайт. В этой конфигурации каждый срез памяти представляет десять гигабайт framebuffer-памяти. Поскольку вычислительные срезы и срезы памяти выделяются вместе, один только объём свободной памяти не определяет, может ли быть запущен новый экземпляр. Требуемые вычислительные срезы также должны быть доступны и соответствовать правильной области памяти. Таблица показывает доступные профили MIG для GPU H100-80GB:

Эти профили показывают, что использование ресурсов MIG в большинстве случаев асимметрично. Некоторые профили предлагают одинаковый объём памяти, но отличаются вычислительной мощностью. Например, и 1g.20gb, и 2g.20gb предоставляют 20 GB памяти, но требуют разного количества вычислительных срезов.

То же относится и к профилям 40 GB: 3g.40gb и 4g.40gb оба используют 40 GB памяти, но требуют разные вычислительные ресурсы.

Это несоответствие между вычислениями и памятью может приводить к результатам размещения, которые на первый взгляд не очевидны.

Потерянная ёмкость

Поскольку вычислительные и срезы памяти не всегда совпадают, некоторые ресурсы GPU могут оставаться неиспользованными, даже когда устройство выглядит полностью занятым. Возьмём самый маленький профиль MIG — 1g.10gb. Этот профиль потребляет один вычислительный срез и один срез памяти. На GPU с восемьюдесятью гигабайтами можно создать семь экземпляров, потому что GPU предоставляет семь вычислительных срезов.

GPU всё ещё имеет восемь срезов памяти. После размещения семи экземпляров 10 гигабайт памяти остаются неиспользованными, или, иначе говоря, это потерянная ёмкость. Вычислительных срезов больше не осталось, поэтому ни один другой экземпляр не может быть запущен. Такое поведение легко не заметить в диаграммах размещения MIG. Эти диаграммы показывают области размещения памяти, и семь экземпляров 1g.10gb выглядят так, будто полностью заполняют GPU. На самом деле ограничивающим фактором являются вычислительные срезы, а не память.

Геометрия размещения

Профили MIG должны соответствовать определённым областям размещения памяти внутри GPU. Профили, которые используют несколько срезов памяти, требуют непрерывной области.

Профиль 3g.40gb потребляет четыре среза памяти. На GPU с объёмом памяти 80 гигабайт это создаёт две допустимые области размещения: срезы памяти 0–3 или 4–7. nvidia-smi — это инструмент командной строки NVIDIA, устанавливаемый вместе с драйвером. Флаг mig -lgi выводит список всех активных экземпляров MIG на хосте — list GPU instances — включая профиль, из которого был создан каждый экземпляр, и его положение в схеме памяти GPU. Вывод содержит колонку placement в формате start:size, где start — это индекс первого среза памяти, который занимает экземпляр, а size — количество срезов, которые он использует.

Экземпляр 3g.40gb с размещением 4:4 начинается с среза памяти 4 и занимает четыре среза, размещаясь во второй области. Экземпляр 4g.40gb с размещением 0:4 занимает первую область — единственную область, где может быть удовлетворено его требование к вычислительным ресурсам. Однако по мере размещения на GPU двух профилей 3g.40gb один вычислительный экземпляр оказывается потерянным.

Важно отметить — и профили 40gb хорошо это показывают — что MIG вводит две области: одну с четырьмя выровненными вычислительными и память-срезами и другую с тремя. Правила размещения MIG требуют, чтобы вычислительные и память-срезы начинались с одной позиции, но они не обязаны заканчиваться одновременно.

Хорошим примером этого является профиль 4g.40gb. Он может быть размещён только начиная с среза памяти 0 и, таким образом, напрямую выравнивается с вычислительным срезом 0. Фрэнк работал с системой Dell PowerEdge XE9680 HGX с восемью GPU H100 80 GB, семь из которых были пустыми.

Когда Фрэнк включил семь виртуальных машин с профилем 4g.40gb, каждая ВМ была размещена в первой области размещения (0–4) GPU H100. Последние четыре среза памяти каждого GPU всё ещё оставались свободными, но в этих областях есть только три вычислительных среза, поэтому разместить там ещё одну ВМ с профилем 4g.40gb невозможно.

Однако можно включить виртуальные машины с профилем vGPU 3g.40gb. Как показано на скриншоте, Фрэнк запустил две ВМ с этим профилем, и они были размещены на GPU 1 и 2.

Имейте в виду, что существующие экземпляры никогда не перестраиваются. То, как настроен GPU, определяет, что может быть запущено следующим. Это означает, что порядок запуска рабочих нагрузок имеет значение, поскольку он влияет на то, какие профили ещё могут быть развёрнуты, даже если кажется, что доступной памяти достаточно.

Поведение размещения

Как описано в части 4, vSphere не использует политики размещения GPU на уровне хоста, когда GPU работают в режиме MIG. Размещение следует тому же подходу, который используется в средах со смешанными размерами: сначала заполняется один GPU, прежде чем переходить к следующему, при этом сохраняется как можно больше вариантов размещения для будущих рабочих нагрузок. Это поведение значительно улучшилось в архитектуре Hopper, но Ampere иногда испытывает трудности с размещением более крупных профилей, потому что не всегда учитывает будущие размещения 4g40gb. (Reddit).

На хостах с более чем одним GPU рабочие нагрузки размещаются на одном GPU до тех пор, пока на этом устройстве больше нельзя разместить запрошенный профиль. Следующая рабочая нагрузка затем размещается на другом GPU. Та же идея применяется и внутри GPU: экземпляры размещаются так, чтобы сохранять максимально возможные непрерывные области, чтобы более крупные профили могли быть развёрнуты позже.

Хороший пример — профиль 3g.40gb. В тестовом кластере Фрэнк очистил семь GPU (кроме GPU 0, на котором выполнялась рабочая нагрузка разработчика) и запустил пять ВМ, каждая с профилем vGPU 3g.40gb. Как показано на скриншоте, первая ВМ была размещена на GPU 0 с placement id 4, оставляя место для будущего профиля 4g.40gb. Когда следующая ВМ была размещена с профилем 3g.40gb, менеджер vGPU выбрал GPU 1, оставив другие GPU открытыми для возможного размещения самого большого профиля — 7g.80gb. При каждом новом размещении менеджер vGPU сначала размещает первый профиль vGPU в позиции placement 4, прежде чем заполнять остальное пространство.

Обратите внимание, что Фрэнк зарегистрировал все эти ВМ на этом хосте, чтобы ограничить область тестирования. В реальных сценариях DRS, вместе с Assignable Hardware, распределяет ВМ между совместимыми хостами ESX в кластере на основе баланса кластера по CPU и памяти и доступности совместимых GPU.

Проектирование каталога профилей

Асимметричное потребление вычислительных срезов заставляет осознанно выбирать профили, которые будут доступны через портал самообслуживания, потому что профили, которые вы включаете, определяют, что пользователи могут запрашивать и насколько эффективно GPU будет использоваться со временем.

Профили 40 гигабайт хорошо демонстрируют этот компромисс. Один GPU может разместить два экземпляра 3g.40gb, но только один 4g.40gb, потому что второй потребовал бы восемь вычислительных срезов, тогда как GPU имеет только семь. Если вы предлагаете только 3g.40gb, один вычислительный срез всегда будет потерян на полностью загруженном GPU. Если вы предлагаете 4g.40gb вместе с более маленькими профилями, вы избегаете этих потерь, но рискуете получить ошибки размещения: профиль 4g.40gb может быть создан только в первой области памяти, поэтому если там уже есть другой экземпляр, размещение становится невозможным независимо от того, сколько памяти осталось.

Профили 20 гигабайт имеют ту же проблему, но в другой форме. Четыре экземпляра 2g.20gb не могут работать на одном GPU — снова требуется восемь вычислительных срезов, но доступно только семь. Если вы добавите профиль 1g.20gb как вариант, можно разместить четвёртую нагрузку на 20 гигабайт, но это увеличивает вероятность появления потерянной ёмкости по мере заполнения GPU экземплярами с небольшой вычислительной нагрузкой.

Не существует конфигурации, которая полностью устраняет это противоречие. Команды платформ должны решить, что важнее: предсказуемость размещения за счёт предложения меньшего количества профилей и более предсказуемого поведения или предложение полного набора профилей с принятием того, что пользователи иногда будут сталкиваться с неудачным размещением или что на некоторых GPU будет оставаться потерянная ёмкость.

Если строгая изоляция не требуется, смешанный режим, описанный в части 6 и части 7, полностью избегает этих ограничений. Четыре рабочие нагрузки по 20 гигабайт и две рабочие нагрузки по 40 гигабайт могут полностью использовать один GPU в средах со смешанными размерами, не оставляя вычислительную ёмкость потерянной.

VMware недавно опубликовала обновлённый набор технических руководств, которые приводят рекомендации в соответствие с архитектурой эпохи VMware Cloud Foundation и с новыми возможностями приложений Microsoft, включая SQL Server 2025 и Windows Server 2025.

Если вы планируете развёртывание VCF, модернизируете существующие среды, стандартизируете платформу, обновляете парк SQL Server или модернизируете инфраструктуру идентификации, мы рекомендуем ознакомиться с этими документами до того, как будет окончательно утверждён ваш следующий дизайн-воркшоп, цикл закупок или план миграции.

Руководство 1: Проектирование Microsoft SQL Server на VMware Cloud Foundation

Для многих команд решение о виртуализации SQL Server уже принято. Как говорится в руководстве: «вопрос больше не в том, виртуализировать ли SQL Server, а в том, как…». И это «как» существенно изменилось в мире VCF. Платформа стала более регламентированной, операционная модель — более стандартизированной, а поддерживающие возможности (хранилище, сеть, управление жизненным циклом, безопасность) эволюционировали с учётом развития аппаратных возможностей и операционных методик.

Обновлённое руководство предназначено для читателей, которые уже понимают как VCF, так и SQL Server. Оно ориентировано на несколько ролей: архитекторов, инженеров/администраторов и DBA.

Несколько моментов, на которые стоит обратить внимание:

• Современные рекомендации по CPU и NUMA теперь учитывают и новое поведение топологии в эпоху VCF. Руководство рассматривает «новые параметры конфигурации топологии vNUMA в VMware Cloud Foundation (VCF)» и объясняет, почему это поведение важно для крупных виртуальных машин SQL Server.
• Чёткая и обновлённая позиция по CPU hot plug в эпоху SQL Server 2025. В руководстве прямо указано: CPU Hot-Add больше не поддерживается в SQL Server 2025, и его не следует включать на таких виртуальных машинах.
• Рекомендации по хранилищу, соответствующие направлению развития VCF. Если вы оцениваете архитектурные варианты vSAN, руководство объясняет, почему vSAN Express Storage Architecture (ESA) привлекателен для заказчиков, переходящих на более современное оборудование, и подчёркивает возможности эффективности ESA, такие как глобальная дедупликация и преимущества сжатия для нагрузок баз данных.
• Пояснения по устаревающим функциям, влияющим на долгоживущие архитектуры. Если в вашей текущей архитектуре активно используются vVols, учтите, что Virtual Volumes объявлены устаревшими, начиная с VCF 9.0 и VMware vSphere Foundation 9.0 (полный отказ запланирован в будущих релизах).
• Операционная реалистичность для мобильности и обслуживания. Руководство рассматривает использование multi-NIC vMotion для снижения риска зависания (stun) при миграции крупных, потребляющих много памяти виртуальных машин SQL, а также отмечает, что VCF внедряет vMotion Notifications, чтобы помочь чувствительным к задержкам и кластер-осведомлённым приложениям безопаснее обрабатывать миграции.

Если вы принимаете решения - это тот документ, который снижает объём переработок, вызванных неожиданностями. Если вы технический специалист - это тот документ, который не позволит вам унаследовать архитектуру в стиле «it depends», которая позже приведёт к простою.

Руководство 2: Проектирование Microsoft SQL Server для высокой доступности на VMware Cloud Foundation

Второе руководство сосредоточено там, где ставки особенно высоки: корректное проектирование доступности SQL Server на VCF без смешивания устаревших предположений, неподдерживаемых конфигураций или подхода «потом исправим» в кластеризации.

Оно написано для смешанной аудитории, включая DBA, администраторов VMware, архитекторов и IT-руководителей. И в нём ясно указано, что «доступность» — это не функция, которую добавляют в конце; выбранная модель защиты должна определяться бизнес-требованиями.

Несколько особенно практичных обновлений:

• Реалии доступности SQL Server 2025, чётко сопоставленные с механизмами защиты. Руководство связывает уровни защиты с современными возможностями обеспечения доступности SQL Server, подчёркивает области, где SQL Server 2025 усиливает архитектуры на базе Availability Groups (AG), и отмечает, что Database Mirroring удалён в SQL Server 2025.
• Рекомендации по согласованию жизненного цикла, которые действительно важны для IT-руководства. Начиная с SQL Server 2025, отмечается, что более старые версии Windows Server вышли из основной поддержки, и рекомендуется использовать Windows Server 2025 или Windows Server 2022 при наличии совместимости — прямой переход к поддерживаемым и обоснованным платформам.
• Современные варианты кластеризации с общими дисками без навязывания устаревших архитектур. Руководство указывает, что в средах эпохи VCF 9 семантика общих дисков для FCI может быть реализована современными способами — подчёркивается использование Clustered VMDKs и явно обозначается движение в сторону отказа от устаревших зависимостей.
• Рекомендации по DRS anti-affinity, предотвращающие «самоорганизованные» события HA. Если узлы кластера SQL работают на одном и том же хосте ESXi «потому что так решил DRS», это не высокая доступность, а отложенный инцидент. Настройте соответствующие правила DRS, чтобы узлы кластера были физически разделены.
• Требования к vMotion Application Notification, изложенные подробно. Руководство описывает использование уведомлений приложений, включая требования, такие как актуальные VMware Tools и рекомендуемая настройка таймаутов — именно те детали, которые команды часто выясняют в условиях уже упавшей системы.
• Рекомендации по vSAN ESA, отражающие текущие возможности. Указывается направление политик ESA и отмечается глобальная дедупликация (впервые представленная в VCF 9.0) как рекомендуемая для определённых сценариев Availability Group SQL Server в пределах одного кластера vSAN.

Это то руководство, которое вы передаёте команде, когда бизнес говорит: «нам нужна более высокая доступность», — и вы хотите, чтобы ответом стало инженерно проработанное решение.

Руководство 3: Виртуализация служб домена Active Directory на VMware Cloud Foundation

Active Directory (AD) Domain Services (DS) — одна из тех служб, о которых не думают до тех пор, пока всё не перестанет работать. Обновлённое руководство по AD DS прямо признаёт это, указывая, что многие организации справедливо рассматривают AD DS как по-настоящему критичное для бизнеса приложение, поскольку аутентификация, доступ к ресурсам и бесчисленные рабочие процессы зависят от него.

Оно также напрямую обращается к сохраняющемуся рефлексу «физического контроллера домена». Благодаря развитию Windows Server и зрелым практикам VCF, в руководстве говорится, что эти улучшения теперь позволяют организациям «безопасно виртуализировать сто процентов своей инфраструктуры AD DS».

Существенно обновлены не общие рекомендации «виртуализируйте это», а современный набор функций и механизмов защиты, которые меняют подход к проектированию и защите виртуальных контроллеров домена:

• В руководстве указано, что лишь несколько усовершенствований существенно изменяют прежние рекомендации, включая Virtualization-Based Security (VBS), Secure Boot, шифрование на уровне виртуальной машины и улучшенную синхронизацию времени в гостевых ВМ — и эти изменения учтены там, где это необходимо.
• Документ явно ориентирован на несколько аудиторий (архитекторов, инженеров/администраторов и руководителей/владельцев процессов), что важно для AD DS, поскольку проектирование и эксплуатация неразделимы.
• Подчёркиваются операционные меры защиты при восстановлении после сбоев. Например, рекомендуется использовать приоритет перезапуска ВМ в vSphere HA, чтобы ключевые инфраструктурные службы запускались раньше после аварийного восстановления.
• Подробно рассматриваются механизмы обеспечения целостности в эпоху виртуализации (например, поведение VM-Generation ID), созданные специально для устранения исторических опасений, связанных со снапшотами и откатами.

Если вы модернизируете инфраструктуру идентификации, консолидируете датацентры или строите частное облако на базе VCF с сильной позицией по безопасности, этот документ обязателен к прочтению. AD DS — это не просто ещё одна рабочая нагрузка. Это сущность, от которой зависит работа всего вашего стека.

Руководство 4: Запуск Microsoft SQL Server Failover Cluster Instance на VMware vSAN платформы VMware Cloud Foundation 9

Если ваша модель обеспечения доступности по-прежнему основана на кластеризации с общими дисками — будь то из-за ограничений приложений, операционных предпочтений или необходимости сохранить модель SQL Server FCI — это руководство является практическим дополнением «как это реально работает на VCF 9» к более общим рекомендациям по HA. Это эталонная архитектура для запуска Microsoft SQL Server Failover Cluster Instance (FCI) с использованием общих дисков на базе vSAN, валидированная как для стандартного кластера vSAN, так и для сценария растянутого кластера vSAN.

Несколько моментов, на которые стоит обратить внимание:

• Нативная поддержка WSFC + общих дисков на vSAN (с подробным описанием механики). В VCF 9 «vSAN обеспечивает нативную поддержку виртуализированных Windows Server Failover Clusters (WSFC)» и «поддерживает SCSI-3 Persistent Reservations (SCSI3PR) на уровне виртуального диска» — ключевое требование для арбитража общих дисков в WSFC.
• Две настройки конфигурации, от которых зависит работоспособность общих дисков. Указывается, что общие диски должны быть подключены к контроллеру с параметром SCSI Bus Sharing, установленным в Physical, и что «режим диска для всех дисков в кластере должен быть установлен в Independent – Persistent», чтобы избежать неподдерживаемой семантики снапшотов на общих дисках.
• Операционные особенности растянутого кластера: задержки, размещение и кворум являются частью архитектуры. Рекомендуется «менее четырёх миллисекунд межсайтовой (round trip) задержки» для SQL-баз данных уровня tier-1 в растянутых кластерах vSAN, а также подчёркивается необходимость правил DRS VM/Host для разделения узлов WSFC по разным хостам.
• Также рекомендуется использовать диск-свидетель кворума, чтобы растянутый кластер сохранял доступность witness-диска при отказе сайта без остановки службы кластера FCI.
• Практический путь миграции с SAN pRDM на общие VMDK vSAN. С самого начала подчёркивается: «перед миграцией настоятельно рекомендуется создать резервную копию», и отмечается, что миграция выполняется офлайн. Описываются шаги по остановке роли кластера, выключению узлов и использованию Storage Migration для преобразования pRDM в VMDK на vSAN ± с обходным решением через PowerCLI (включая пример кода) в случае, если выбор формата диска в мастере Migrate недоступен.

Это руководство, которое вы передаёте команде, когда требование звучит как «нам нужна семантика FCI», и вы хотите получить осознанную, поддерживаемую архитектуру.

Что дальше

Если вы активно проектируете, обновляете или мигрируете инфраструктуру, рассматривайте эти руководства в контексте команд:

• Команды платформы: сначала прочитайте руководство по SQL Server, чтобы согласовать значения по умолчанию вычислений/хранилища/сети с поведением SQL.
• DBA и инженеры инфраструктуры: прочитайте руководство по HA до того, как зафиксируете модель кластеризации, стратегию хранения и модель обслуживания.
• Команды по идентификации и безопасности: прочитайте руководство по AD DS, чтобы согласовать меры настройки, восстановления и операционные процессы с современными механизмами защиты виртуализации.
• Команды, использующие (или стандартизирующие) SQL Server FCI: прочитайте руководство по FCI на vSAN, чтобы зафиксировать требования к общим дискам, позицию по политике хранения и ограничения растянутого кластера до внедрения.

Ниже приведены прямые ссылки для скачивания упомянутых документов:

• Architecting Microsoft SQL Server on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-vcf
• Virtualizing Active Directory Domain Services on VMware Cloud Foundation:
  https://www.vmware.com/docs/active-directory-domain-services-vcf
• Architecting Microsoft SQL Server for High Availability on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-ha-vcf
• Running Microsoft SQL Server Failover Cluster Instance on VMware vSAN with VMware Cloud Foundation 9:
  https://www.vmware.com/docs/mssql-fci-vcf-9

В этой части статьи мы продолжаем рассказывать об итогах 2025 года в плане серверной и настольной виртуализации на базе российских решений. Первую часть статьи можно прочитать тут.

Возможности VDI (виртуализации рабочих мест)

Импортозамещение коснулось не только серверной виртуализации, но и инфраструктуры виртуальных рабочих столов (VDI). После ухода VMware Horizon (сейчас это решение Omnissa) и Citrix XenDesktop российские компании начали внедрять отечественные VDI-решения для обеспечения удалённой работы сотрудников и центрального управления рабочими станциями. К 2025 году сформировался пул новых продуктов, позволяющих развернуть полнофункциональную VDI-платформу на базе отечественных технологий.

Лидерами рынка VDI стали решения, созданные в тесной связке с платформами серверной виртуализации. Так, компания «ДАКОМ М» (бренд Space) помимо гипервизора SpaceVM предложила продукт Space VDI – систему управления виртуальными рабочими столами, интегрированную в их экосистему. Space VDI заняла 1-е место в рейтинге российских VDI-решений 2025 г., набрав 228 баллов по совокупности критериев.

Её сильные стороны – полностью собственная разработка брокера и агентов (не опирающаяся на чужие open-source) и наличие всех компонентов, аналогичных VMware Horizon: Space Dispatcher (диспетчер VDI, альтернатива Horizon Connection Server), Space Agent VDI (клиентский агент на виртуальной машине, аналог VMware Horizon Agent), Space Client для подключения с пользовательских устройств, и собственный протокол удалённых рабочих столов GLINT. Протокол GLINT разработан как замена зарубежных (RDP/PCoIP), оптимизирован для работы в российских сетях и обеспечивает сжатие/шифрование трафика. В частности, заявляется поддержка мультимедиа-ускорения и USB-перенаправления через модуль Mediapipe, который служит аналогом Citrix HDX. В результате Space VDI предоставляет высокую производительность графического интерфейса и мультимедиа, сравнимую с мировыми аналогами, при этом полностью вписывается в отечественный контур безопасности.

Вторым крупным игроком стала компания HOSTVM с продуктом HostVM VDI. Этот продукт изначально основыван на открытой платформе UDS (VirtualCable) и веб-интерфейсе на Angular, но адаптирован российским разработчиком. HostVM VDI поддерживает широкий набор протоколов – SPICE, RDP, VNC, NX, PCoIP, X2Go, HTML5 – фактически покрывая все популярные способы удалённого доступа. Такая всеядность упрощает миграцию с иностранных систем: например, если ранее использовался протокол PCoIP (как в VMware Horizon), HostVM VDI тоже его поддерживает. Решение заняло 2-е место в отраслевом рейтинге с 218 баллами, немного уступив Space VDI по глубине интеграции функций.

Своеобразный подход продемонстрировал РЕД СОФТ. Их продукт «РЕД Виртуализация» является, в первую очередь, серверной платформой (форком oVirt на KVM) для развертывания ВМ. Однако благодаря тесной интеграции с РЕД ОС и другим ПО компании, Red Виртуализация может использоваться и для VDI-сценариев. Она заняла 3-е место в рейтинге VDI-платформ. По сути, РЕД предлагает создать инфраструктуру на базе своего гипервизора и доставлять пользователям рабочие столы через стандартные протоколы (для Windows-ВМ – RDP, для Linux – SPICE или VNC). В частности, поддерживаются протоколы VNC, SPICE и RDP, что покрывает базовые потребности. Кроме того, заявлена возможность миграции виртуальных машин в РЕД Виртуализацию прямо из сред VMware vSphere и Microsoft Hyper-V, что упрощает переход на решение.

Далее, существуют специализированные отечественные VDI-продукты: ROSA VDI, Veil VDI, Termidesk и др.

• ROSA VDI (разработка НТЦ ИТ РОСА) базируется на том же oVirt и ориентирована на интеграцию с российскими ОС РОСА.
• Veil VDI – решение компаний «НИИ Масштаб»/Uveon – представляет собственную разработку брокера виртуальных рабочих столов; оно также попало в топ-5 рейтинга.
• Termidesk – ещё одна проприетарная система, замыкающая первую шестёрку лидеров. Каждая из них предлагает конкурентоспособные функции, хотя по некоторым пунктам уступает лидерам. Например, Veil VDI и Termidesk пока набрали меньше баллов (182 и 174 соответственно) и, вероятно, имеют более узкую специализацию или меньшую базу внедрений.
  

Общей чертой российских VDI-платформ является ориентация на безопасность и импортозамещение. Все они зарегистрированы как отечественное ПО и могут применяться вместо VMware Horizon, Citrix или Microsoft RDS. С точки зрения пользовательского опыта, основные функции реализованы: пользователи могут подключаться к своим виртуальным рабочим столам с любых устройств (ПК, тонкие клиенты, планшеты) через удобные клиенты или даже браузер. Администраторы получают централизованную консоль для создания образов ВМ, массового обновления ПО на виртуальных рабочих столах и мониторинга активности пользователей. Многие решения интегрируются с инфраструктурой виртуализации серверов – например, Space VDI напрямую работает поверх гипервизора SpaceVM, ROSA VDI – поверх ROSA Virtualization, что упрощает установку.

Отдельно стоит отметить поддержку мультимедийных протоколов и оптимизацию трафика. Поскольку качество работы VDI сильно зависит от протокола передачи картинки, разработчики добавляют собственные улучшения. Мы уже упомянули GLINT (Space) и широкий набор протоколов в HostVM. Также используется протокол Loudplay – это отечественная разработка в области облачного гейминга, адаптированная под VDI.

Некоторые платформы (например, Space VDI, ROSA VDI, Termidesk) заявляют поддержку Loudplay наряду со SPICE/RDP, чтобы обеспечить плавную передачу видео и 3D-графики даже в сетях с высокой задержкой. Терминальные протоколы оптимизированы под российские условия: так, Termidesk применяет собственный кодек TERA для сжатия видео и звука. В результате пользователи могут комфортно работать с графическими приложениями, CAD-системами и видео в своих виртуальных десктопах.

С точки зрения масштабируемости VDI, российские решения способны обслуживать от десятков до нескольких тысяч одновременных пользователей. Лабораторные испытания показывают, что Space VDI и HostVM VDI могут управлять тысячами виртуальных рабочих столов в распределенной инфраструктуре (с добавлением необходимых серверных мощностей). Важным моментом остаётся интеграция со средствами обеспечения безопасности: многие платформы поддерживают подключение СЗИ для контроля за пользователями (DLP-системы, антивирусы на виртуальных рабочих местах) и могут работать в замкнутых контурах без доступа в интернет.

Таким образом, к концу 2025 года отечественные VDI-платформы покрывают основные потребности удалённой работы. Они позволяют централизованно развертывать и обновлять рабочие места, сохранять данные в защищённом контуре датацентра и предоставлять сотрудникам доступ к нужным приложениям из любой точки. При этом особый акцент сделан на совместимость с российским стеком (ОС, ПО, требования регуляторов) и на возможность миграции с западных систем с минимальными затратами (поддержка разных протоколов, перенос ВМ из VMware/Hyper-V). Конечно, каждой организации предстоит выбрать оптимальный продукт под свои задачи – лидеры рынка (Space VDI, HostVM, Red/ROSA) уже имеют успешные внедрения, тогда как нишевые решения могут подойти под специальные сценарии.

Кластеризация, отказоустойчивость и управление ресурсами

Функциональность, связанная с обеспечением высокой доступности (HA) и отказоустойчивости, а также удобством управления ресурсами, является критичной при сравнении платформ виртуализации. Рассмотрим, как обстоят дела с этими возможностями у российских продуктов по сравнению с VMware vSphere.

Кластеризация и высокая доступность (HA)

Почти все отечественные системы поддерживают объединение хостов в кластеры и автоматический перезапуск ВМ на доступных узлах в случае сбоя одного из серверов – аналог функции VMware HA. Например, SpaceVM имеет встроенную поддержку High Availability для кластеров: при падении хоста его виртуальные машины автоматически запускаются на других узлах кластера.

Basis Dynamix, VMmanager, Red Virtualization – все они также включают механизмы мониторинга узлов и перезапуска ВМ при отказе, что отражено в их спецификациях (наличие HA подтверждалось анкетами рейтингов). По сути, обеспечение базовой отказоустойчивости сейчас является стандартной функцией для любых платформ виртуализации. Важно отметить, что для корректной работы HA требуется резерв мощности в кластере (чтобы были свободные ресурсы для поднятия упавших нагрузок), поэтому администраторы должны планировать кластеры с некоторым запасом хостов, аналогично VMware.

Fault Tolerance (FT)

Более продвинутый режим отказоустойчивости – Fault Tolerance, при котором одна ВМ дублируется на другом хосте в режиме реального времени (две копии работают синхронно, и при сбое одной – вторая продолжает работать без прерывания сервиса). В VMware FT реализован для критичных нагрузок, но накладывает ограничения (например, количество vCPU). В российских решениях прямая аналогия FT практически не встречается. Тем не менее, некоторые разработчики заявляют поддержку подобных механизмов. В частности, Basis Dynamix Enterprise в материалах указывал наличие функции Fault Tolerance. Однако широкого распространения FT не получила – эта технология сложна в реализации, а также требовательна к каналам связи. Обычно достаточен более простой подход (HA с быстрым перезапуском, кластерные приложения на уровне ОС и т.п.). В критических сценариях (банковские системы реального времени и др.) могут быть построены решения с FT на базе метрокластеров, но это скорее штучные проекты.

Снапшоты и резервное копирование

Снимки состояния ВМ (snapshots) – необходимая функция для безопасных изменений и откатов. Все современные платформы (zVirt, SpaceVM, Red и прочие) поддерживают создание мгновенных снапшотов ВМ в рабочем состоянии. Как правило, доступны возможности делать цепочки снимков, однако требования к хранению диктуют, что постоянно держать много снапшотов нежелательно (как и в VMware, где они влияют на производительность). Для резервного копирования обычно предлагается интеграция с внешними системами бэкапа либо встроенные средства экспорта ВМ.

Например, SpaceVM имеет встроенное резервное копирование ВМ с возможностью сохранения бэкапов на удалённое хранилище. VMmanager от ISPsystem также предоставляет модуль бэкапа. Тем не менее, организации часто используют сторонние системы резервирования – здесь важно, что у российских гипервизоров обычно открыт API для интеграции. Почти все продукты предоставляют REST API или SDK, позволяющий автоматизировать задачи бэкапа, мониторинга и пр. Отдельные вендоры (например, Basis) декларируют принцип API-first, что упрощает связку с оркестраторами резервного копирования и мониторинга.

Управление ресурсами и балансировка

Мы уже упоминали наличие аналогов DRS в некоторых платформах (автоматическое перераспределение ВМ). Кроме этого, важно, как реализовано ручное управление ресурсами: пулы CPU/памяти, приоритеты, квоты. В VMware vSphere есть ресурсные пулы и shares-приоритеты. В российских системах подобные механизмы тоже появляются. zVirt, например, позволяет объединять хосты в логические группы и задавать политику размещения ВМ, что помогает распределять нагрузку. Red Virtualization (oVirt) исторически поддерживает задание весов и ограничений на ЦП и ОЗУ для групп виртуальных машин. В Basis Dynamix управление ресурсами интегрировано с IaC-инструментами – можно через Terraform описывать необходимые ресурсы, а платформа сама их выделит.

Такое тесное сочетание с DevOps-подходами – одно из преимуществ новых продуктов: Basis и SpaceVM интегрируются с Ansible, Terraform для автоматического развертывания инфраструктуры как кода. Это позволяет компаниям гибко управлять ИТ-ресурсами и быстро масштабировать кластеры или развертывать новые ВМ по шаблонам.

Управление кластерами

Центральная консоль управления кластером – обязательный компонент. Аналог VMware vCenter в отечественных решениях присутствует везде, хотя может называться по-разному. Например, у Space – SpaceVM Controller (он же выполняет роль менеджера кластера, аналог vCenter). У zVirt – собственная веб-консоль, у Red Virtualization – знакомый интерфейс oVirt Engine, у VMmanager – веб-панель от ISPsystem. То есть любой выбранный продукт предоставляет единый интерфейс для управления всеми узлами, ВМ и ресурсами. Многие консоли русифицированы и достаточно дружелюбны. Однако по отзывам специалистов, удобство администрирования ещё требует улучшений: отмечается, что ряд операций в отечественных платформах более трудоёмкие или требуют «танцев с бубном» по сравнению с отлаженным UI VMware. Например, на Хабре приводился пример, что создание простой ВМ в некоторых системах превращается в квест с редактированием конфигурационных файлов и чтением документации, тогда как в VMware это несколько кликов мастера создания ВМ. Это как раз то направление, где нашим решениям ещё есть куда расти – UX и простота администрирования.

В плане кластеризации и отказоустойчивости можно заключить, что функционально российские платформы предоставляют почти весь минимально необходимый набор возможностей. Кластеры, миграция ВМ, HA, снапшоты, бэкап, распределенная сеть, интеграция со сториджами – всё это реализовано (см. сводную таблицу ниже). Тем не менее, зрелость реализации зачастую ниже: возможны нюансы при очень крупных масштабах, не все функции могут быть такими же «отполированными» как у VMware, а администрирование требует большей квалификации.

Продолжение следует...

Виртуализация давно стала неотъемлемой частью корпоративной ИТ-инфраструктуры, позволяя эффективнее использовать серверное оборудование и быстро развертывать новые сервисы. До недавнего времени российский рынок практически полностью зависел от зарубежных продуктов – особенно от VMware, на долю которого приходилось до 95% внедрений. Однако после 2022 года ситуация резко изменилась: VMware покинула российский рынок, отключив аккаунты пользователей и прекратив поддержку.

Это оставило компании без обновлений, техподдержки и возможности покупки новых лицензий. Одновременно регуляторы ужесточили требования: с 1 января 2025 года значимые объекты критической информационной инфраструктуры (КИИ) обязаны использовать только отечественное ПО. В результате переход на российские системы виртуализации из опции превратился в необходимость, и за три года рынок претерпел заметную консолидацию.

По данным исследования компании «Код Безопасности», уже 78% российских организаций выбирают отечественные средства виртуализации. В реестре российского ПО на 2025 год значатся порядка 92 решений для серверной виртуализации, из которых реально «живых» около 30, а активно используемых – не более десятка. За короткий срок появились аналоги западных продуктов «большой тройки» (VMware, Microsoft Hyper-V, Citrix) и собственные разработки российских компаний. Рассмотрим новейшие российские платформы виртуализации серверов и инфраструктуры виртуальных рабочих мест (VDI) и проанализируем их архитектуру, производительность, безопасность, возможности VDI, а также функции кластеризации и управления ресурсами. Отдельно сравним их с VMware VCF/vSphere по функциональности, зрелости технологий, совместимости и поддержке – и определим, какие решения наиболее перспективны для импортозамещения VMware в корпоративных ИТ России.

Архитектура решений виртуализации

Российские платформы виртуализации 2025 года представлены широким спектром архитектурных подходов. Условно можно выделить две ключевые категории: классическая архитектура и гиперконвергентная архитектура (HCI). Также различаются технологические основы: часть решений опирается на открытый исходный код (форки oVirt, OpenStack, Proxmox и др.), тогда как другие являются проприетарными разработками.

Классическая архитектура

В классической схеме вычислительные узлы, системы хранения (СХД) и сети реализуются отдельными компонентами, объединёнными в единый кластер виртуализации. Такой подход близок к VMware vSphere и проверен десятилетиями: он даёт максимальную гибкость, позволяя подключать внешние высокопроизводительные СХД, использовать существующие сетевые инфраструктуры и масштабировать каждый слой независимо (например, наращивать хранение без изменения серверов). Для организаций с уже развернутыми дорогими СХД и развитой экспертизой администраторов этот вариант наиболее понятен.

Многие отечественные продукты поддерживают классическую модель. Например, “Ред Виртуализация” (решение компании РЕД СОФТ на базе KVM/oVirt), zVirt от Orion soft, SpaceVM (платформа компании «ДАКОМ М»), Rosa Virtualization, VMmanager от ISPsystem и Numa vServer (Xen-based) – все они ориентированы на традиционную архитектуру с интеграцией внешних хранилищ и сетей.

Архитектурно они во многом схожи с VMware (например, оVirt-платформы реализуют подключение SAN-хранилищ, динамическую балансировку ресурсов и т.п. «из коробки»). Однако есть и недостатки классического подхода: более высокая стоимость отдельных компонентов (CAPEX), требовательность к квалификации узких специалистов, сложность диагностики сбоев (не всегда очевидно, в каком слое проблема). Развёртывание классической инфраструктуры может занимать больше времени, поскольку нужно поэтапно настроить и интегрировать разнородные компоненты внутри единой платформы.

Гиперконвергентная инфраструктура (HCI)

В HCI все основные функции – вычисления, хранение, сеть – объединены на каждом узле и управляются через единую программную платформу. Локальные диски серверов объединяются программно в распределённое хранилище (часто на основе Ceph или аналогов), а сеть виртуализуется средствами самой платформы. Такой подход упрощает масштабирование: добавление нового узла сразу увеличивает и CPU/RAM, и объём хранения. Гиперконвергенция особенно хорошо подходит для распределённых площадок и филиалов, где нет штата ИТ-специалистов – достаточно поставить несколько одинаковых узлов, и система автонастроится без тонкой ручной оптимизации каждого слоя.

В России к HCI-решениям относятся, например, vStack (платформа в составе холдинга ITG на базе FreeBSD и гипервизора bhyve), «Кибер Инфраструктура» (решение компании «Киберпротект», развившей технологии Acronis), Р-платформа (российская приватная облачная платформа), Горизонт-ВС и др. – они изначально спроектированы как гиперконвергентные. Некоторые HCI-системы позволяют выходить за рамки встроенного хранения – например, Кибер Инфраструктура и Горизонт-ВС поддерживают подключение внешних блочных СХД, комбинируя подходы.

Открытый код или собственные разработки?

Многие отечественные продукты выросли из популярных open-source проектов. Например, решения на основе oVirt – это упомянутые выше zVirt, Red Виртуализация, ROSA Virtualization, HostVM и др. Их преимущество – быстрое получение базовой функциональности (live migration, подключение SAN, кластеры HA и т.д.) благодаря наследию oVirt/Red Hat. Однако после ухода Red Hat из oVirt сообщество ослабло, и российским командам пришлось форкать код и развивать его самим.

Orion soft, например, пошла по пути создания собственного бэкенда поверх ядра oVirt, сумев сохранить совместимость, но упростив и улучшив часть функций для пользователей. Другой популярный открытый проект – Proxmox VE – тоже получил российские форки (например, «Альт Виртуализация», GloVirt), что позволяет заказчикам использовать знакомый интерфейс PVE с поддержкой отечественной компанией.

Есть и решения на базе OpenStack – эта платформа хорошо масштабируется и подходит для построения частных облаков IaaS. Так, AccentOS CE – российская облачная платформа на основе OpenStack – получила сертификат ФСТЭК осенью 2025 г. Тем не менее, OpenStack-системы (например, частное облако VK Cloud) часто критикуют за избыточную сложность для задач традиционной виртуализации и проблемы стабильности отдельных ВМ под высокими нагрузками хранения. Наконец, существуют продукты на базе Xen – в частности, Numa vServer построен на открытом гипервизоре xcp-ng (форк Citrix XenServer), что даёт вариант для тех, кто привык к Xen.

Помимо форков, на рынке появились принципиально новые разработки. К ним относятся SpaceVM, Basis Dynamix, VMmanager и др., где компании создали собственные платформы управления, опираясь на комбинацию различных open-source компонентов, но реализуя уникальные возможности. Например, SpaceVM и Basis Dynamix заявляют о полном проприетарном стеке – разработчики утверждают, что не используют готовые open-source продукты внутри, а все компоненты (гипервизор, драйверы, диспетчер ресурсов) созданы самостоятельно. Такой подход требует больше усилий, но позволяет глубже интегрировать систему с отечественными ОС и средствами кибербезопасности, а также активно внедрять API-first и DevOps-интеграции. В итоге, сегодня российский рынок виртуализации предлагает решения на любой вкус – от максимально близких к VMware аналогов на базе KVM до совершенно новых платформ с оригинальной архитектурой.

Производительность и масштабируемость

Один из ключевых вопросов для корпоративных клиентов – способен ли отечественный гипервизор обеспечить производительность и масштаб, сопоставимые с vSphere. Практика показывает, что большинство российских платформ уже поддерживают необходимые уровни масштабирования: кластеры на десятки узлов, сотни и тысячи виртуальных машин, live migration и распределение нагрузки между хостами. Например, платформа SpaceVM официально поддерживает кластеры до 96 серверов, Selectel Cloud – до 2500 узлов, Red Виртуализация – до 250 хостов в одном датацентре.

Многие разработчики вообще не указывают жестких ограничений на размер кластера, утверждая, что он линеен (ISP VMmanager протестирован на 350+ узлов, 1000+ ВМ). В реальных внедрениях обычно речь идёт о десятках серверов, что этим решениям вполне по силам. Однако из опыта миграций известны и проблемы: так, эксперты отмечают, что у zVirt иногда возникают сложности при росте кластера более 50 узлов. Первые «тревожные звоночки» появлялись уже около 20 хостов, но в новых версиях горизонтальная масштабируемость доведена до 50–60 узлов, что для большинства сред достаточно. Подобные нюансы следует учитывать при проектировании – предельно возможный масштаб у разных продуктов разнится, и при планировании очень крупных инсталляций лучше привлечь вендора или интегратора для оценки нагрузок.

По производительности виртуальных машин отечественные гипервизоры стараются минимизировать накладные расходы. Так, vStack HCP заявляет о оверхеде всего 2–5% к CPU при виртуализации, то есть близкой к нативной производительности. Это достигнуто за счёт легковесного гипервизора (базирующегося на bhyve) и оптимизированного I/O стека. Большинство других решений используют проверенные гипервизоры (KVM, Xen), у которых производительность также высока. С точки зрения нагрузки на оперативную память и хранилище – многое зависит от механизмов дедупликации, компрессии и прочих оптимизаций в конкретной реализации.

Здесь можно отметить, что многие российские платформы уже внедрили современные технологии оптимизации ресурсов: поддержка NUMA для эффективной работы с многопроцессорными узлами, возможность тонкого выделения ресурсов (thin provisioning дисков, memory ballooning) и т.д. Например, по данным рейтинга Компьютерры, Basis Dynamix и SpaceVM набрали максимальные баллы по критериям вертикальной и горизонтальной масштабируемости, а также поддержки Intel VT-x/AMD-V виртуализации, NUMA и даже GPU-passthrough. То есть функционально они не уступают VMware в возможностях задействовать современное оборудование.

Отдельно стоит упомянуть работу с графическими нагрузками. В сфере VDI и 3D-приложений критична поддержка GPU-виртуализации. Здесь российские разработчики сделали заметный прогресс. SpaceVM изначально ориентирован на сценарии с графическими рабочими станциями: платформа поддерживает как passthrough GPU для выделения целой видеокарты ВМ, так и технологию FreeGRID – собственную разработку для виртуализации ресурсов NVIDIA-GPU без риска лицензионной блокировки.

По сути, FreeGRID выступает аналогом технологии NVIDIA vGPU (GRID), но адаптированным к ограничениям поставок – это актуально, поскольку официальные лицензии NVIDIA в России недоступны. Благодаря этому SpaceVM активно используют организации, которым нужны высокопроизводительные графические ВМ: конструкторские бюро (CAD/CAE), геоинформационные системы, видеомонтаж и др. Другие платформы также не отстают: zVirt и решения на базе oVirt умеют пробрасывать физические GPU внутрь ВМ, а HostVM и ряд VDI-платформ заявляют поддержку технологии виртуализации графических процессоров для нужд 3D-моделирования. Таким образом, в плане работы с тяжелыми графическими нагрузками отечественные продукты закрывают основные потребности.

Стоит отметить, что автоматическое распределение ресурсов и балансовка нагрузки – функции, известные в VMware как DRS (Distributed Resource Scheduler) – начинают появляться и в российских решениях. Например, zVirt реализует модуль автоматического распределения виртуальных машин по хостам, аналогичный DRS. Это значит, что платформа сама перераспределяет ВМ при изменении нагрузок, поддерживая равномерное потребление ресурсов. Кроме того, большинство продуктов поддерживают «горячую миграцию» (Live Migration) – перенос работающей ВМ между хостами без простоя, а также миграцию хранилищ на лету (Storage vMotion) – например, в zVirt есть возможность "перетаскивать" виртуальные диски между датацентрами без остановки ВМ. Эти функции критичны для обеспечения непрерывности сервисов при обслуживании оборудования или ребалансировке нагрузки.

Резюмируя, производительность российских гипервизоров уже находится на уровне, достаточном для многих корпоративных задач, а по некоторым параметрам они предлагают интересные инновации (минимальный оверхэд у vStack, поддержка GPU через FreeGRID у SpaceVM и т.п.). Тем не менее, при планировании очень нагруженных или масштабных систем следует внимательно относиться к тестированию конкретного продукта под своей нагрузкой – практика показывает, что в пилотных проектах не всегда выявляются узкие места, которые могут проявиться на продакшен-системе. Важны также оперативность вендора при оптимизации производительности и наличие у него экспертизы для помощи заказчику в тюнинге – эти аспекты мы рассмотрим в следующих статьях при сравнении опций поддержки.

Безопасность и соответствие требованиям

Вопрос кибербезопасности и соответствия регуляторным требованиям (ФСТЭК, Закон о КИИ, ГОСТ) является определяющим для многих российских предприятий, особенно государственных и критической инфраструктуры. Отечественные решения виртуализации учитывают эти аспекты с самого начала разработки. Во-первых, практически все крупные платформы включены в Единый реестр российского ПО, что подтверждает их юридическую «отечественность» и позволяет использовать их для импортозамещения в госорганизациях. Более того, ряд продуктов прошёл добровольную сертификацию в ФСТЭК России по профильным требованиям безопасности.

Особое внимание уделяется сетевой безопасности в виртуальной среде. Одной из угроз в датацентрах является горизонтальное распространение атак между ВМ по внутренней сети. Для борьбы с этим современные платформы внедряют микросегментацию сети и распределённые виртуальные брандмауэры. Например, zVirt содержит встроенные средства SDN (Software-Defined Networking) для сегментации трафика – администратор может разделить виртуальную сеть на множество изолированных сегментов и централизованно задать политики доступа между ними. Эта функциональность, требуемая ФСТЭК для защиты виртуальных сред, реализована по умолчанию и позволяет соответствовать требованиям закона по сегментированию значимых объектов КИИ и ГосИС.

Дополнительно компания Orion soft (разработчик zVirt) рекомендует использовать совместно с гипервизором продукт vGate от компании «Код Безопасности». vGate – это межсетевой экран уровня гипервизора, который интегрируется с платформой виртуализации. Работая на уровне гипервизора, vGate перехватывает и фильтрует трафик между всеми ВМ, применяя централизованные политики безопасности. Разработчики сделали ставку на микросегментацию: каждый узел vGate хранит полный набор правил, что позволяет при миграции ВМ сразу переносить и её сетевые политики.

vGate сертифицирован ФСТЭК как межсетевой экран класса «Б» с 4-м уровнем доверия, поэтому его связка с zVirt закрывает требования регулятора для защиты виртуальных сегментов КИИ. В случае комбинированного использования, как отмечают эксперты, правила безопасности контролируются одновременно на уровне платформы (zVirt SDN) и на уровне гипервизора (vGate), дополняя друг друга. Например, если политика zVirt разрешает определённый трафик между ВМ, а политика vGate запрещает, пакет будет блокирован – то есть действует наиболее строгий из двух наборов правил. Такой «двойной заслон» повышает уверенность в защите.

Кроме сетевых экранов, встроенные механизмы безопасности практически обязательны для всех современных платформ. Российские решения включают разграничение доступа и аутентификацию корпоративного уровня: реализованы ролевые модели (RBAC), интеграция с LDAP/Active Directory для централизованного управления учетными записями, поддержка многофакторной аутентификации администраторов и журналирование действий с возможностью отправки логов на SIEM-системы. По этим пунктам разница с VMware не такая и большая – например, Basis Dynamix, SpaceVM и Red Виртуализация имеют полный набор RBAC/LDAP/2FA и получили максимально возможные оценки за безопасность в независимом рейтинге.

Дополнительно некоторые решения обеспечивают контроль целостности и доверенную загрузку (Trusted Boot) за счёт интеграции с отечественными защищёнными ОС. Например, гипервизоры могут устанавливаться поверх сертифицированных ОС (РЕД ОС, Astra Linux), что обеспечивает соответствие по требованиям НДВ (недекларированных возможностей) и использование российских криптосредств.

В контексте соответствия требованиям регуляторов важна и сертификация самих платформ виртуализации. На конец 2025 года сертифицированных по профильным требованиям ФСТЭК именно гипервизоров немного (преимущественно решения для гостевых ОС специального назначения). Однако, как отмечалось, платформы часто используют сертифицированные СЗИ «поверх» (антивирусы, СОВ, vGate и др.) для обеспечения соответствия. Кроме того, крупнейшие заказчики – госсектор, банки – проводили оценочные испытания продуктов в своих пилотных зонах. Например, при миграции в Альфа-Банке и АЛРОСА основным драйвером был закон о КИИ, и в обоих случаях итоговый выбор пал на отечественные гипервизоры (SpaceVM и zVirt соответственно) после тщательного тестирования безопасности. Таким образом, можно сказать, что российские системы виртуализации в целом готовы к работе в защищённых контурах. Они позволяют реализовать требуемую сегментацию, поддерживают российские криптоалгоритмы (при использовании соответствующих ОС и библиотек), а при правильной настройке обеспечивают изоляцию ВМ не хуже зарубежных аналогов.

Нельзя не затронуть и вопрос устойчивости к атакам и сбоям. Эксперты отмечают, что по методам защиты виртуальная инфраструктура не сильно отличается от физической – нужны регулярные обновления безопасности, сильные пароли и ограничение доступа привилегированных пользователей. Основной вектор атаки на гипервизоры в России – компрометация учётных данных администраторов, тогда как эксплойты уязвимостей встречаются гораздо реже. Это значит, что внедрение RBAC/2FA, о которых сказано выше, существенно снижает риски. Также важно строить резервное копирование на уровне приложений и данных, а не полагаться только на механизмы платформы. Как отмечают представители банковского сектора, добиться требуемого по стандартам времени восстановления (RTO) только силами гипервизора сложно – необходимо комбинировать различные уровни (репликация критичных систем, отказоустойчивые кластеры, резервные площадки). В целом же, за три года уровень зрелости безопасности российских продуктов заметно вырос: многие проблемы, ранее считавшиеся нерешаемыми, уже устранены или существуют понятные обходные пути. Производители активно учитывают требования заказчиков, внедряя наиболее востребованные функции безопасности в приоритетном порядке.

Продолжение следует...

Серверная платформа виртуализации VMware Cloud Foundation (VCF 9) обеспечивает непревзойдённые преимущества для инфраструктуры виртуальных рабочих столов (VDI). Даже после выделения бизнес-группы VMware End User Computing (EUC) в состав отдельной компании Omnissa основы этого комплексного решения остаются неизменными. Однако выпуск VCF 9.0 заслуживает повторного рассмотрения этих основ, чтобы показать, насколько устойчивой остаётся платформа.

VCF 9.0 объединяет основу частного облака (vSphere, vSAN, NSX) с облачной автоматизацией (VCF Automation), интегрированным Kubernetes (VMware vSphere Kubernetes Service / VKS) и другими передовыми сервисами для VCF, такими как VMware Private AI Services и VMware Data Services Manager (DSM). Эти и многие другие инновации работают совместно с решением Omnissa Horizon VDI, обеспечивая изначально безопасный, оптимизированный и масштабируемый фундамент для самых требовательных виртуальных рабочих столов.

Запуск Horizon на VCF 9.0 позволяет клиентам воспользоваться полным набором сервисов единой платформы частного облака. VCF предоставляет домены рабочих нагрузок, оркестрированные обновления, сетевую изоляцию на основе VPC и современный API потребления. Это платформа, которая рассматривает рабочие столы как полноправные рабочие нагрузки.

Безопасность и соответствие требованиям

Безопасность — это то, где VCF сразу проявляет свои сильные стороны. Используйте межсетевой экран NSX, чтобы применить политику наименьших привилегий к Horizon Connection Server, UAG и пулу рабочих столов без направляющего трафик hairpin-маршрута через внешние файрволы. Конструкции VPC в VCF 9.0 позволяют создавать воспроизводимый сетевой периметр для каждой функции Horizon:

• Edge (UAG)
• Brokering (Connection Servers)
• Рабочие столы
• Общие сервисы

Эти меры защиты масштабируются вместе с инфраструктурой, а не усложняют её. VCF 9.0 также представляет комплекс встроенных функций безопасности и соответствия требованиям, критически важных для VDI-сред:

• Централизованное управление сетевыми политиками с NSX усиливает защиту латерального трафика для чувствительных VDI-рабочих столов, соответствуя строгим регуляторным требованиям.
• Микросегментация и изоляция VPC позволяют привязывать политики к объектам, а не подсетям, что повышает устойчивость в продакшене и упрощает аудит.
• Неизменяемые (immutable) снапшоты, защита от вымогателей и интегрированное аварийное восстановление с vSAN ESA и VMware Live Recovery обеспечивают непрерывность бизнеса и быстрое восстановление после атак или сбоев, что критично для поддержания доступности рабочих столов и соответствия требованиям.

Для отраслей с жёсткими нормами (здравоохранение, финансы, госучреждения) сертификации безопасности VCF (TLS 1.3, FIPS 140-3, DISA STIG) позволяют рабочим средам соответствовать самым строгим стандартам.

Эффективность и оптимизация ресурсов

Благодаря дедупликации хранения, расширенным механизмам управления памятью и более высокой загрузке хостов, VCF 9.0 обеспечивает значительное снижение совокупной стоимости владения (TCO). Эффективность затрат в этом контексте — это не просто «купить меньше серверов». Речь идёт о том, чтобы преобразовать каждый ресурс — вычисления, хранение, сеть и операционные накладные расходы — в большее количество продуктивных пользователей без ущерба для их опыта.

• Улучшенные коэффициенты консолидации CPU и памяти позволяют размещать больше одновременных рабочих столов на сервере, что напрямую снижает инфраструктурные расходы и упрощает масштабирование крупных развертываний.
• vSAN ESA с глобальной дедупликацией может уменьшить затраты на хранение для постоянных VDI-пулов, а фоновые операции минимизируют влияние на производительность для пользователей.
• Политики хранения vSAN могут назначаться для каждого пула, чтобы образы для сотрудников с типовыми задачами не вызывали то же потребление ресурсов хранения, что и пулы, насыщенные данными или графикой. Такая точность направляет IOPS туда, где они нужнее всего, и устраняет практику чрезмерного резервирования ресурсов «на всякий случай».

Благодаря функции Memory Tiering в VCF vSphere постоянно держит горячие страницы в DRAM и перемещает холодные на локальные NVMe, фактически используя локальные NVMe как вторичный уровень памяти. В недавних тестах Login Enterprise это позволило добиться стабильного двукратного увеличения плотности ВМ на хост. Эта возможность значительно повышает эффективность использования оборудования, позволяя запускать больше виртуальных рабочих столов на меньшей инфраструктуре.

Высокая производительность

VCF 9.0 предоставляет основу, которая делает производительность Horizon предсказуемой. Это начинается с вычислительных ресурсов: распределённый планировщик vSphere (DRS) помогает гарантировать, что динамичные пулы рабочих столов распределяются с учётом локальности NUMA по физическому кластеру. Это обеспечивает попадание выделенных vCPU на один NUMA-узел, уменьшая межсокетные переходы, снижая задержки и повышая общую плавность работы. Особенно критично это во время «штормов загрузки» (boot storms) и всплесков активности приложений.

Память

Память часто является узким местом в VDI. Как отмечалось ранее, Memory Tiering в VCF 9 увеличивает плотность без обычного негативного влияния на производительность или пользовательский опыт. Особенно это заметно для пулов с низкими требованиями к «горячей» памяти (например, рабочих мест сотрудников с типовыми задачами). Практический эффект в периоды пиков (утренние входы, массовые запуски приложений и т.д.) выражается в меньшем количестве зависаний и снижении задержек ввода.

Хранение

Благодаря vSAN (особенно архитектуре Express Storage Architecture на NVMe) вы получаете адаптированный под записи метод хранения и возможность использовать политики хранения на уровне пула рабочих столов, оптимизированные под конкретную задачу:

• RAID-1 и повышенное количество страйпов для особо требовательных пользователей
• RAID-5/6 для сотрудников с типовыми задачами
• Object-space reservations для эталонных золотых образов рабочих столов, которые испытывают серьёзную нагрузку на чтение при использовании слоёв приложений

Поскольку управление реализовано полностью на базе политик, нет необходимости избыточно проектировать каждый пул под худший сценарий, но инфраструктура при этом остаётся оптимизированной для ежедневных нагрузок клонирования, развёртывания обновлений и утренних пиков входа. Итог - стабильные задержки под нагрузкой и более быстрое открытие приложений, когда все кликают одновременно.

Сеть

Сетевые сервисы NSX выполняются в ядре гипервизора, что позволяет избегать прогона через физическую инфраструктуру, что забирает ресурсы хоста и увеличивает задержки. В сочетании с сегментацией VPC пулы рабочих столов получают детерминированные маршруты с меньшим количеством переходов. Результат — меньше накладных расходов и больше пропускной способности для действительно важного трафика. Кроме того, NSX Distributed Firewall (лицензируется отдельно как часть VMware vDefend) может применять политику межсетевого экрана для east-west трафика прямо на pNIC хоста, исключая маршрутизацию через внешние устройства и уменьшая колебания задержек.

Графика

Horizon с NVIDIA vGPU на VCF позволяет выбирать vGPU-профили для каждого пула, сохраняя при этом преимущества DRS для оптимального размещения рабочих столов. Это означает, что можно консолидировать требовательных 3D-пользователей и более лёгкие графические задачи на одних и тех же физических хостах, поддерживая высокую утилизацию GPU.

Операции второго дня

Управление жизненным циклом и парком инфраструктуры в VCF — это мгновенное преимущество для администраторов, которым приходилось балансировать обслуживание и доступность пулов рабочих столов. VCF 9.0 оркестрирует задачи жизненного цикла платформы по доменам рабочих нагрузок, что позволяет выполнять обновления в узкие временные окна без длительных простоев и без оставления кластеров в смешанном состоянии. Это поддерживает эффективность DRS и согласованность политик хранения, обеспечивая доступность и производительность пулов рабочих столов. VCF выполняет поэтапные обновления всего стека, по домену, с проверками работоспособности и операционными процессами.

Автоматизация жизненного цикла частного облака упрощает патчинг, обновления и планирование ёмкости для крупных развертываний Horizon, позволяя администраторам сосредоточиться на пользовательском опыте и инновациях, а не на повторяющихся операциях. Инструменты мониторинга и устранения неполадок на уровне всей платформы ускоряют решение проблем и оптимизируют показатели пользовательского опыта, минимизируя простой и повышая продуктивность.

Сценарий использования: Developer Workbench как сервис

С VKS и дополнительным сервисом DSM организации могут подключать лёгкие сервисы на базе Kubernetes и внутренние инструменты разработки непосредственно к пулам рабочих столов разработчиков. Это превращает VDI из «удалённого рабочего стола» в управляемую платформу рабочих пространств разработчика с сервисами по запросу.

• VKS — это полноценный независимый сервис с быстрым жизненным циклом и декларативными API потребления.
• Инженеры платформ и команды разработки могут быстро развертывать среды разработчиков на базе VKS, значительно сокращая время настройки dev/test.
• Разработчики могут самостоятельно создавать пространства имен (namespaces), VKS-кластеры и получать доступ к PostgreSQL/MySQL и другим сервисам, управляемым DSM. Всё маркируется на уровне платформы с учётом стоимости, политик и требований к суверенитету данных.

Дополнительные сценарии использования

Помимо традиционных постоянных и непостоянных рабочих столов, комбинация VCF 9.0 + Omnissa Horizon открывает ряд расширенных возможностей:

• Использование растянутых или мультисайтовых архитектур для расширения VDI-сервисов между облаками VCF, поддерживая гибкое масштабирование и сценарии аварийного восстановления.
• Инженеры платформ и команды разработки могут самостоятельно и быстро разворачивать среды разработчиков на базе VKS, резко сокращая время подготовки dev/test.
• Интегрированные VMware Private AI Services и поддержка vGPU как сервиса позволяют организациям легко развертывать виртуальные рабочие столы с поддержкой AI.

Также недавно был представлен документ VMware, описывающий эталонную архитектуру «Omnissa Horizon 8 на VMware Cloud Foundation».

Эта эталонная архитектура документирует проверенный, готовый к промышленной эксплуатации дизайн для запуска Omnissa Horizon 8 на VMware Cloud Foundation (VCF). Она создана, чтобы строго ответить на простой вопрос: как сегодня максимально быстро, безопасно и экономично доставлять корпоративные виртуальные рабочие столы? Эталонная архитектура подчёркивает практическую инженерную проработку, повторяемые шаблоны и измеримые результаты, формируя схему сервиса, которую организации могут уверенно применять - будь то модернизация существующей среды Horizon или создание новой платформы.

Итоги

Даже несмотря на то, что Omnissa теперь работает как независимая компания, фундаментальные требования к облачной инфраструктурной платформе для виртуальных рабочих столов остаются неизменными: согласованная сегментация и безопасность, производительность, масштабируемость, управление жизненным циклом и возможность добавлять полезные сервисы. Именно это и обеспечивает VCF 9.0 - поэтому он остаётся лучшей основой для Horizon Desktops.

Если вам важна инфраструктура виртуальных рабочих столов, которая подходит не только для сегодняшних задач, но и готова к будущему, то запуск Horizon на VCF 9.0 - идеальное решение. Он устраняет все классические проблемы - безопасность, доступность, производительность и обновления - одновременно открывая доступ к функциям следующего поколения, таким как AI, рабочие столы для разработчиков и мультисайтовое масштабирование.

NVIDIA Run:ai ускоряет операции AI с помощью динамической оркестрации ресурсов, максимизируя использование GPU, обеспечивая комплексную поддержку жизненного цикла AI и стратегическое управление ресурсами. Объединяя ресурсы между средами и применяя продвинутую оркестрацию, NVIDIA Run:ai значительно повышает эффективность GPU и пропускную способность рабочих нагрузок.

Недавно VMware объявила, что предприятия теперь могут развертывать NVIDIA Run:ai с встроенной службой VMware vSphere Kubernetes Services (VKS) — стандартной функцией в VMware Cloud Foundation (VCF). Это поможет предприятиям достичь оптимального использования GPU с NVIDIA Run:ai, упростить развертывание Kubernetes и поддерживать как контейнеризованные нагрузки, так и виртуальные машины на VCF. Таким образом, можно запускать AI- и традиционные рабочие нагрузки на единой платформе.

Давайте посмотрим, как клиенты Broadcom теперь могут развертывать NVIDIA Run:ai на VCF, используя VMware Private AI Foundation with NVIDIA, чтобы развертывать кластеры Kubernetes для AI, максимизировать использование GPU, упростить операции и разблокировать GenAI на своих приватных данных.

NVIDIA Run:ai на VCF

Хотя многие организации по умолчанию запускают Kubernetes на выделенных серверах, такой DIY-подход часто приводит к созданию изолированных инфраструктурных островков. Это заставляет ИТ-команды вручную создавать и управлять службами, которые VCF предоставляет из коробки, лишая их глубокой интеграции, автоматизированного управления жизненным циклом и устойчивых абстракций для вычислений, хранения и сетей, необходимых для промышленного AI. Именно здесь платформа VMware Cloud Foundation обеспечивает решающее преимущество.

vSphere Kubernetes Service — лучший способ развертывания Run:ai на VCF

Наиболее эффективный и интегрированный способ развертывания NVIDIA Run:ai на VCF — использование VKS, предоставляющего готовые к корпоративному использованию кластеры Kubernetes, сертифицированные Cloud Native Computing Foundation (CNCF), полностью управляемые и автоматизированные. Затем NVIDIA Run:ai развертывается на этих кластерах VKS, создавая единую, безопасную и устойчивую платформу от аппаратного уровня до уровня приложений AI.

Ценность заключается не только в запуске Kubernetes, но и в запуске его на платформе, решающей базовые корпоративные задачи:

• Снижение совокупной стоимости владения (TCO) с помощью VCF: уменьшение инфраструктурных изолятов, использование существующих инструментов и навыков без переобучения, единое управление жизненным циклом всех инфраструктурных компонентов.
• Единые операции: основаны на привычных инструментах, навыках и рабочих процессах с автоматическим развертыванием кластеров и GPU-операторов, обновлениями и управлением в большом масштабе.
• Запуск и управление Kubernetes для большой инфраструктуры: встроенный, сертифицированный CNCF Kubernetes runtime с полностью автоматизированным управлением жизненным циклом.
• Поддержка в течение 24 месяцев для каждой минорной версии vSphere Kubernetes (VKr) - это снижает нагрузку при обновлениях, стабилизирует окружения и освобождает команды для фокусировки на ценности, а не на постоянных апгрейдах.
• Лучшая конфиденциальность, безопасность и соответствие требованиям: безопасный запуск чувствительных и регулируемых AI/ML-нагрузок со встроенными средствами управления, приватности и гибкой безопасностью на уровне кластеров.

Сетевые возможности контейнеров с VCF

Сети Kubernetes на «железе» часто плоские, сложные для настройки и требующие ручного управления. В крупных централизованных кластерах обеспечение надежного соединения между приложениями с разными требованиями — сложная задача. VCF решает это с помощью Antrea, корпоративного интерфейса контейнерной сети (CNI), основанного на CNCF-проекте Antrea. Он используется по умолчанию при активации VKS и обеспечивает внутреннюю сетевую связность, реализацию политик сети Kubernetes, централизованное управление политиками и операции трассировки (traceflow) с уровня управления NSX. При необходимости можно выбрать Calico как альтернативу.

Расширенная безопасность с vDefend

Разные приложения в общем кластере требуют различных политик безопасности и контроля доступа, которые сложно реализовать последовательно и масштабируемо. Дополнение VMware vDefend для VCF расширяет возможности безопасности, позволяя применять сетевые политики Antrea и микросегментацию уровня «восток–запад» вплоть до контейнера. Это позволяет ИТ-отделам программно изолировать рабочие нагрузки AI, конвейеры данных и пространства имен арендаторов с помощью политик нулевого доверия. Эти функции необходимы для соответствия требованиям и предотвращения горизонтального перемещения в случае взлома — уровень детализации, крайне сложный для реализации на физических коммутаторах.

Высокая отказоустойчивость и автоматизация с VMware vSphere

Это не просто удобство, а основа устойчивости инфраструктуры. Сбой физического сервера, выполняющего многодневное обучение, может привести к значительным потерям времени. VCF, основанный на vSphere HA, автоматически перезапускает такие рабочие нагрузки на другом узле.

Благодаря vMotion возможно обслуживание оборудования без остановки AI-нагрузок, а Dynamic Resource Scheduler (DRS) динамически балансирует ресурсы, предотвращая перегрузки. Подобная автоматическая устойчивость отсутствует в статичных, выделенных средах.

Гибкое управление хранилищем с политиками через vSAN

AI-нагрузки требуют разнообразных типов хранения — от высокопроизводительного временного пространства для обучения до надежного объектного хранения для наборов данных. vSAN позволяет задавать эти требования (например, производительность, отказоустойчивость) индивидуально для каждой рабочей нагрузки. Это предотвращает появление новых изолированных инфраструктур и необходимость управлять несколькими хранилищами, как это часто бывает в средах на «голом железе».

Преимущества NVIDIA Run:ai

• Максимизация использования GPU: динамическое выделение, дробление GPU и приоритизация задач между командами обеспечивают максимально эффективное использование мощной инфраструктуры.
• Масштабируемые сервисы AI: поддержка развертывания больших языковых моделей (инференс) и других сложных AI-задач (распределённое обучение, тонкая настройка) с эффективным масштабированием ресурсов под изменяющуюся нагрузку.

Обзор архитектуры

Давайте посмотрим на высокоуровневую архитектуру решения:

• VCF: базовая инфраструктура с vSphere, сетями VCF (включая VMware NSX и VMware Antrea), VMware vSAN и системой управления VCF Operations.
• Кластер Kubernetes с поддержкой AI: управляемый VCF кластер VKS, обеспечивающий среду выполнения AI-нагрузок с доступом к GPU.
• Панель управления NVIDIA Run:ai: доступна как услуга (SaaS) или для локального развертывания внутри кластера Kubernetes для управления рабочими нагрузками AI, планирования заданий и мониторинга.
• Кластер NVIDIA Run:ai: развернут внутри Kubernetes для оркестрации GPU и выполнения рабочих нагрузок.
• Рабочие нагрузки data science: контейнеризированные приложения и модели, использующие GPU-ресурсы.

Эта архитектура представляет собой полностью интегрированный программно-определяемый стек. Вместо того чтобы тратить месяцы на интеграцию разрозненных серверов, коммутаторов и систем хранения, VCF предлагает единый, эластичный и автоматизированный облачный операционный подход, готовый к использованию.

Диаграмма архитектуры

Существует два варианта установки панели управления NVIDIA Run:ai:

• SaaS: панель управления размещена в облаке (см. https://run-ai-docs.nvidia.com/saas). Локальный кластер Run:ai устанавливает исходящее соединение с облачной панелью для выполнения рабочих нагрузок AI. Этот вариант требует исходящего сетевого соединения между кластером и облачным контроллером Run:ai.
• Самостоятельное размещение: панель управления Run:ai устанавливается локально (см. https://run-ai-docs.nvidia.com/self-hosted) на кластере VKS, который может быть совместно используемым или выделенным только для Run:ai. Также доступен вариант с изолированной установкой (без подключения к сети).

Вот визуальное представление инфраструктурного стека:

Сценарии развертывания

Сценарий 1: Установка NVIDIA Run:ai на экземпляре VCF с включенной службой vSphere Kubernetes Service

Предварительные требования:

• Среда VCF с узлами ESX, оснащёнными GPU
• Кластер VKS для AI, развернутый через VCF Automation
• GPU настроены как DirectPath I/O, vGPU с разделением по времени (time-sliced) или NVIDIA Multi-Instance GPU (MIG)

Если используется vGPU, NVIDIA GPU Operator автоматически устанавливается в рамках шаблона (blueprint) развертывания VCFA.

Основные шаги по настройке панели управления NVIDIA Run:ai:

1. Подготовьте ваш кластер VKS, назначенный для роли панели управления NVIDIA Run:ai, выполнив все необходимые предварительные условия.
2. Создайте секрет с токеном, полученным от NVIDIA Run:ai, для доступа к контейнерному реестру NVIDIA Run:ai.
3. Если используется VMware Data Services Manager, настройте базу данных Postgres для панели управления Run:ai; если нет — Run:ai будет использовать встроенную базу Postgres.
4. Добавьте репозиторий Helm и установите панель управления с помощью Helm.

Основные шаги по настройке кластера:

1. Подготовьте кластер VKS, назначенный для роли кластера, с выполнением всех предварительных условий, и запустите диагностический инструмент NVIDIA Run:ai cluster preinstall.
2. Установите дополнительные компоненты, такие как NVIDIA Network Operator, Knative и другие фреймворки в зависимости от ваших сценариев использования.
3. Войдите в веб-консоль NVIDIA Run:ai, перейдите в раздел Resources и нажмите "+New Cluster".
4. Следуйте инструкциям по установке и выполните команды, предоставленные для вашего кластера Kubernetes.

Преимущества:

• Полный контроль над инфраструктурой
• Бесшовная интеграция с экосистемой VCF
• Повышенная надежность благодаря автоматизации vSphere HA, обеспечивающей защиту длительных AI-тренировок и серверов инференса от сбоев аппаратного уровня — критического риска для сред на «голом железе».

Сценарий 2: Интеграция vSphere Kubernetes Service с существующими развертываниями NVIDIA Run:ai

Почему именно vSphere Kubernetes Service:

• Управляемый VMware Kubernetes упрощает операции с кластерами
• Тесная интеграция со стеком VCF, включая VCF Networking и VCF Storage
• Возможность выделить отдельный кластер VKS для конкретного приложения или этапа — разработка, тестирование, продакшн

Шаги:

1. Подключите кластер(ы) VKS к существующей панели управления NVIDIA Run:ai, установив кластер Run:ai и необходимые компоненты.
2. Настройте квоты GPU и политики рабочих нагрузок в пользовательском интерфейсе NVIDIA Run:ai.
3. Используйте возможности Run:ai, такие как автомасштабирование и разделение GPU, с полной интеграцией со стеком VCF.

Преимущества:

• Простота эксплуатации
• Расширенная наблюдаемость и контроль
• Упрощённое управление жизненным циклом

Операционные инсайты: преимущество "Day 2" с VCF

Наблюдаемость (Observability)

В средах на «железе» наблюдаемость часто достигается с помощью разрозненного набора инструментов (Prometheus, Grafana, node exporters и др.), которые оставляют «слепые зоны» в аппаратном и сетевом уровнях. VCF, интегрированный с VCF Operations (часть VCF Fleet Management), предоставляет единую панель мониторинга для наблюдения и корреляции производительности — от физического уровня до гипервизора vSphere и кластера Kubernetes.

Теперь в системе появились специализированные панели GPU для VCF Operations, предоставляющие критически важные данные о том, как GPU и vGPU используются приложениями. Этот глубокий AI-ориентированный анализ позволяет гораздо быстрее выявлять и устранять узкие места.

Резервное копирование и восстановление (Backup & Disaster Recovery)

Velero, интегрированный с vSphere Kubernetes Service через vSphere Supervisor, служит надежным инструментом резервного копирования и восстановления для кластеров VKS и pod’ов vSphere. Он использует Velero Plugin for vSphere для создания моментальных снапшотов томов и резервного копирования метаданных напрямую из хранилища Supervisor vSphere.

Это мощная стратегия резервирования, которая может быть интегрирована в планы аварийного восстановления всей AI-платформы (включая состояние панели управления Run:ai и данные), а не только бездисковых рабочих узлов.

Итог: Bare Metal против VCF для корпоративного AI

NVIDIA Run:ai на VCF ускоряет корпоративный ИИ

Развертывание NVIDIA Run:ai на платформе VCF позволяет предприятиям создавать масштабируемые, безопасные и эффективные AI-платформы. Независимо от того, начинается ли внедрение с нуля или совершенствуются уже существующие развертывания с использованием VKS, клиенты получают гибкость, высокую производительность и корпоративные функции, на которые они могут полагаться.

VCF позволяет компаниям сосредоточиться на ускорении разработки AI и повышении отдачи от инвестиций (ROI), а не на рискованной и трудоемкой задаче построения и управления инфраструктурой. Она предоставляет автоматизированную, устойчивую и безопасную основу, необходимую для промышленных AI-нагрузок, позволяя NVIDIA Run:ai выполнять свою главную задачу — максимизировать использование GPU.

Недавно компания Orion soft анонсировала релизы платформы виртуализации - zVirt 4.5 и zVirt 5.0. Давайте посмотрим, что нового обещает разработчик отечественной платформы виртуализации.

zVirt 4.5: вектор на производительность и виртуализацию сетей

По словам Orion soft, релиз 4.5 сфокусирован на двух крупных направлениях:

1. Рост производительности (внутренние оптимизации стека),
2. Дальнейшее развитие сетевой виртуализации (SDN). Это не «косметика», а серия внутренних апгрейдов, которые готовят почву под 5.0. Подробный перечень фич компания не публиковала, акцент именно на эти векторы развития.

Что это означает на практике:

• Ускорение «горячих» путей данных. В реальной эксплуатации это обычно выражается в уменьшении задержек операций ввода-вывода ВМ, росте пропускной способности при миграциях и репликации, а также в снижении накладных расходов управляющих сервисов. В контексте последних релизов zVirt компания уже поднимала потолок репликации и улучшала экспорт метрик/логов — версия 4.5 логично продолжает эту линию, но уже как «внутренний» апгрейд ядра платформы.
• Упрочнение SDN-стека. С версии 4.0/4.2 zVirt продвигал микросегментацию и управляемые сети через UI; в 4.5 ожидаем дальнейшее выравнивание производительности и функциональности SDN под крупные инсталляции (много проектов/сетей, избыточные связи, тонкая политика East-West). Идея — дать базис для грядущей миграции сетевых конфигураций из vSphere/NSX-подобных сценариев, заявленных к 5.0.

Вывод для архитекторов: 4.5 — это «подкапотный» релиз, который не меняет ваши процессы, но подготавливает площадку: стабильнее SDN, выше пропускная способность, а значит — меньше рисков при масштабировании кластеров и при переходе на версию 5.0.

zVirt 5.0: крупные продуктовые сдвиги

Для zVirt 5.0 Orion soft публично называл ряд ключевых возможностей, которые заметно расширяют зону автоматизации и упрощают миграцию с VMware-ландшафтов:

1. Storage DRS (распределение нагрузки по хранилищам)

Идеология — объединить несколько доменов хранения в логический «кластер» и автоматически балансировать размещение/миграцию дисков/ВМ по политикам (запас по IOPS/latency/ёмкости, «горячие» тома и т. п.). Это сокращает ручные операции, снижает риск «перекоса» томов хранения (LUN) и ускоряет реакцию на всплески нагрузки. Orion soft ранее уже демонстрировал Storage DRS в линейке 4.x, ну а в 5.0 ожидается консолидация и развитие этого направления как «функции по умолчанию» для больших инсталляций.

Практический эффект:

• Более предсказуемые SLA на уровне хранилища для VMs/VDIs.
• Упрощение сценариев расширения емкости (add capacity -> автоматический ребаланс).
• Меньше ручных миграций хранилищ в пиковые часы.

2. Упрощённый инсталлятор (быстрое развертывание/апгрейды)

Цель — сократить TTV (time-to-value): меньше шагов, больше проверок совместимости и готовности (сети, CPU-фичи, хранилища, сертификаты), шаблоны для типовых топологий (Hosted Engine, Standalone, edge-кластера). Это критично для массовых миграций с VMware: когда десятки площадок поднимаются параллельно, выигрыш в часах на площадку умножается на десятки.

3. Управление аппаратной репликацией на СХД

Речь о DR на уровне массивов (например, YADRO TATLIN.UNIFIED, Huawei Dorado и др.) с оркестрацией из консоли zVirt. Преимущества аппаратной репликации — RPO до 0 сек при синхронных схемах и низкая нагрузка на гипервизоры/SAN. План аварийного переключения становится «кнопкой» в едином UI. В 4.x уже были интеграции и демонстрации такого подхода, а версия 5.0 укрепляет это как нативный сценарий с централизованным управлением планами DR.

Практический эффект:

• Единый контрольный контур для DR (агентская и аппаратная репликации)
• Меньше конфликтов за ресурсы между продуктивом и DR-задачами
• Формализованные RTO/RPO для аудита

4. Terraform-провайдер

Провайдер позволяет декларативно описывать кластера, ВМ, сети/SDN-объекты, политики, хранилища — и воспроизводить их через CI/CD. Это даёт привычную для DevOps-команд «инфраструктуру как код» поверх zVirt, ускоряя создание однотипных стендов, DR-сайтов и «blue/green» сред.

Практический эффект:

• Контроль версий для инфраструктуры (git-история ваших кластеров)
• Воспроизводимость площадок (dev -> stage -> prod)
• Быстрый откат/повторение конфигураций по слияниям (merges).

5. Миграция конфигураций с VMware vSphere на SDN zVirt

Отдельно заявлена возможность импорта сетевых конфигураций из VMware-ландшафтов в SDN-модель zVirt: перенос порт-групп, сегментации, ACL/микросегментации и прочее. Это важная часть «бесшовной» стратегии импортозамещения: раньше боль была не только «перенести ВМ», но и воссоздать сетевую политику («зашитую» в vSphere/NSX). Версия 5.0 обещает автоматизировать этот пласт работ.

Практический эффект:

• Сокращение ошибок при ручном переносе сетей
• Предсказуемость инфраструктуры безопасности после миграции
• Ускорение cut-over окон при переездах больших ферм ВМ.

Как готовиться к zVirt 4.5/5.0 в производственной среде

1. Проверить лимиты и совместимость (ядра, CPU-фичи, сетевые карты, Mellanox/Intel, fabric-параметры, NUMA-profile, лимиты по миграциям/сетям/ВМ) — чтобы апгрейды прошли «в стык», без регрессий. Актуальные лимиты и best practices доступны в вики Orion soft.
2. Нормализовать SDN-модель: привести именование сетей/проектов к единому стандарту, сверить микросегментацию и схему ACL — это упростит будущий импорт конфигураций и policy-driven-балансировку. В версии 4.2 уже был сделан большой шаг по SDN/микросегментации.
3. Обновить процессы DR: если у вас есть массивы с аппаратной репликацией — инвентаризовать пары массивов, RPO/RTO, каналы межплощадочной связи; продумать, какие сервисы уйдут на аппаратную репликацию, а какие останутся на агентской (уровень гипервизора).
4. Заложить IaC-подход: начать описывать парки ВМ, сети, хранилища в Terraform (как минимум — черновые манифесты), чтобы к моменту выхода провайдера под 5.0 ваш репозиторий уже отражал фактическую инфраструктуру.

Более подробно о новых возможностях zVirt 4.5 и zVirt 5.0 можно почитать вот тут.

На конференции VMware Explore 2025 компания Broadcom объявила, что службы VMware Private AI Services теперь входят в стандартную поставку VMware Cloud Foundation 9.0 (VCF 9.0). То есть VCF превращается в полноценную AI-native платформу частного облака: из коробки доступны (или будут доступны) сервисы для работы с моделями, наблюдаемость за GPU, среда исполнения для моделей и агент-фреймворк, плюс дорожная карта с MCP, multi-accelerator и AI-ассистентом для VCF.

Платформа VCF 9.0 уже находится в статусе General Availability и доступна с июня 2025, а выход служб Private AI Services в составе подписки планируется к началу первого квартала 2026 финансового года Broadcom.

Давайте посмотрим на состав и функции VMware Private AI Services:

Слой AI-сервисов в VCF 9.0

Что «входит по умолчанию» в Private AI Services (становится частью подписки VCF 9.0):

• GPU Monitoring — телеметрия и наблюдаемость графических карт.
• Model Store — репозиторий и версионирование моделей.
• Model Runtime — сервисный слой для развертывания/экспонирования моделей (endpoints).
• Agent Builder — сборка/оркестрация «агентов» поверх LLM.
• Vector Database & Data Indexing/Retrieval — индексация корпоративных данных и RAG-потоки.
  

Эти возможности поставляются как native services платформы, а не «надстройка» — и это важная архитектурная деталь: AI становится частью инфраструктуры, живущей в тех же сущностных/безопасностных доменах, что и виртуальные машины и контейнеры.

Также были анонсированы следуюие продукты и технологии в рамках дорожной карты:

• Intelligent Assist for VCF — LLM-ассистент для диагностики и самопомощи в VCF (пока как tech preview для on-prem/air-gapped и cloud-моделей).
• Model Context Protocol (MCP) — стандартная, управляемая интеграция ассистентов с инструментами и БД (Oracle, MSSQL, ServiceNow, GitHub, Slack, PostgreSQL и др.).
• Multi-accelerator Model Runtime — единая среда исполнения для AMD и NVIDIA GPU без переработки приложений; поддержка NVIDIA Blackwell, B200, ConnectX-7/BlueField-3 с технологией Enhanced DirectPath I/O.
• Multi-tenant Models-as-a-Service — безопасное шаринг-использование моделей между пространствами имен/линиями бизнеса.

Ядро VCF 9.0: что поменялось в самой платформе

Единая операционная плоскость

VCF 9.0 переносит фокус на «One interface to operate» (VCF Operations) и «One interface to consume» (VCF Automation): единая модель политик, API и общий движок жизненного цикла. Это снижает расхождение инструментов и обучаемость. На практике это дает унифицированное управление инфраструктурой, health/patch/compliance из одной консоли, централизованные функции IAM/SSO/сертификатов, анализ корреляции логов и другие возможности.

Примеры экранов и функций, доступных в VCF Operations: обзор по всем инстансам, геокарта, статус сертификатов с автообновлением, NetOps-дэшборды (NSX health, VPC, flows), интеграция Live Recovery и LogAssist.

Слой потребления (для разработчиков/проектных команд)

• GitOps (Argo CD) как встроенная модель доставки, Istio Service Mesh для zero-trust/observability трафика, единый контроль политик по проектам.
• vSphere Kubernetes Service (VKS) — функции enterprise-K8s, доступные прямо из VCF.
• Native vSAN S3 Object Store — S3-совместимый API хранилища объектов на vSAN, без внешних лицензий/модулей.

Все это — официальные «новые в 9.0» элементы, влияющие на скорость доставки сервисов и безопасность.

Производительность и эффективность

• NVMe Memory Tiering — расширение оперативной памяти за счет NVMe для высокочастотных/in-memory нагрузок.
• vSAN Global Deduplication (ESA) — постпроцессинговая глобальная дедупликация на уровне кластера.
• Улучшенные data paths + опциональный DPU offload — снижение задержек в east-west контуре, предсказуемость отклика.

• Security Operations Dashboard - непрерывный compliance-сканер (CIS/NIST/кастомные baselines), identity & cert management, «drift»-контроль.
• Встроенные chargeback/showback и cost dashboards (TCO-прозрачность, прогнозирование, возврат/reclaim неиспользуемых ресурсов).

Аппаратные улучшения/сетевой стек для AI

VCF 9.0 выравнивает работу «больших» AI-нагрузок на частной инфраструктуре:

• Поддержка NVIDIA Blackwell (включая RTX PRO 6000 Blackwell Server Edition, B200, HGX с NVSwitch), GPUDirect RDMA/Storage, Enhanced DirectPath I/O - при этом сохраняются «классические» возможности vSphere (vMotion, HA, DRS, Live Patching).
• Совместная работа с AMD: ROCm Enterprise AI и Instinct MI350 для задач fine-tuning/RAG/inference. Это не «плагин», а интегрированная часть VCF и экосистемы VMware Private AI Foundation with NVIDIA.

Как это интегрируется в вашм бизнес-процессы

Типовые сценарии, которые теперь проще закрывать «из коробки»:

• Models-as-a-Service: реестр -> развертывание -> публикация endpoint-ов -> контроль версий/квот -> многоарендность.
• Агенты поверх LLM: ускоренный старт с Agent Builder + подключение к корпоративным данным через индексирование/вектора.
• RAG-потоки с политиками и аудитом: источники данных под управлением VCF, контроль доступа на уровне платформы, видимость (observability).
• Доставка сервисов K8s: GitOps (Argo CD), сервис-меш (Istio), S3-объекты на vSAN для артефактов/данных.

Лицензирование/доставка и пути обновления

• GA: VCF 9.0 доступен с 17 июня 2025.
• Службы Private AI Services обещаны как часть подписки VCF 9.0 в Q1 FY26 от Broadcom.
• Официальный документ с фичами и путями миграции VCF <-> VVF 9.0 доступен тут.

Вывод

VCF 9.0 — это не просто «еще одна» версия с оптимизациями. За счет включения Private AI Services в базовую платформу и сдвига на «one interface to operate/consume», VCF превращает AI-нагрузки в основу частного облака, сохраняя корпоративные политики, комплаенс и привычные SRE-процессы — от GPU до GitOps.

Весной этого года вышел новый релиз бесплатной утилиты SexiGraf (Overwatch Nexus), предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом средстве в октябре прошлого года. Этот продукт был сделан энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным решениям для мониторинга серверов ESX и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Что нового

• VMware vSAN Inventory — расширенная инвентаризация объектов vSAN.
• PowerShell Core 7.4.6 LTS — обновление среды скриптов.
• Ubuntu 22.04.5 LTS — современная версия операционной системы.
• Apache 2.4.63 — обновлённый веб-сервер.

Улучшения и исправления

• Возможность добавления SSH-ключа при деплое — повышает безопасность и удобство разграничения доступа.
• Добавлен сбор события DrsSoftRuleViolationEvent в event-коллектор — расширение мониторинга нарушений правил DRS.
• Исправлено неконсистентное значение GuestId в инвентаре VM (различие между vmx и vmtools) — повышение точности данных.
• Различные багфиксы — общее улучшение стабильности и надежности.

Миграция и формат поставки

SexiGraf с этой версии доступен исключительно в виде нового OVA-образа, обновления в виде патчей больше не выпускаются (за исключением экстренных случаев). Чтобы обновиться, пользователи должны:

1. Экспортировать данные из текущего SexiGraf-модуля.
2. Импортировать данные в новый OVA-модуль через функционал Export/Import.

Виртуальный модуль SexiGraf 0.99l уже доступен для загрузки и развёртывания. Установка происходит стандартным способом через OVA (например, через vSphere, OVF Tool и т.п.). Версия поддерживает переопределение root-пароля и SSH-ключа на этапе деплоя, что упрощает настройку и повышает безопасность.

Новая версия платформы VMware Cloud Foundation 9.0, включающая компоненты виртуализации серверов и хранилищ VMware vSphere 9.0, а также виртуализации сетей VMware NSX 9, привносит не только множество улучшений, но и устраняет ряд устаревших технологий и функций. Многие возможности, присутствовавшие в предыдущих релизах ESX (ранее ESXi), vCenter и NSX, в VCF 9 объявлены устаревшими (deprecated) или полностью удалены (removed). Это сделано для упрощения архитектуры, повышения безопасности и перехода на новые подходы к архитектуре частных и публичных облаков. Ниже мы подробно рассмотрим, каких функций больше нет во vSphere 9 (в компонентах ESX и vCenter) и NSX 9, и какие альтернативы или рекомендации по миграции существуют для администраторов и архитекторов.

Почему важно знать об удалённых функциях?

Новые релизы часто сопровождаются уведомлениями об устаревании и окончании поддержки прежних возможностей. Игнорирование этих изменений может привести к проблемам при обновлении и эксплуатации. Поэтому до перехода на VCF 9 следует проанализировать, используете ли вы какие-либо из перечисленных ниже функций, и заранее спланировать отказ от них или переход на новые инструменты.

VMware vSphere 9: удалённые и устаревшие функции ESX и vCenter

В VMware vSphere 9.0 (гипервизор ESX 9.0 и сервер управления vCenter Server 9.0) прекращена поддержка ряда старых средств администрирования и внедрены новые подходы. Ниже перечислены основные функции, устаревшие (подлежащие удалению в будущих версиях) или удалённые уже в версии 9, а также рекомендации по переходу на современные альтернативы:

• vSphere Auto Deploy (устарела) – сервис автоматического развертывания ESXi-хостов по сети (PXE-boot) объявлен устаревшим. В ESX 9.0 возможность Auto Deploy (в связке с Host Profiles) будет удалена в одном из следующих выпусков линейки 9.x.
  
  Рекомендация: если вы использовали Auto Deploy для бездискового развёртывания хостов, начните планировать переход на установку ESXi на локальные диски либо использование скриптов для автоматизации установки. В дальнейшем управление конфигурацией хостов следует осуществлять через образы vLCM и vSphere Configuration Profiles, а не через загрузку по сети.

• vSphere Host Profiles (устарела) – механизм профилей хоста, позволявший применять единые настройки ко многим ESXi, будет заменён новой системой конфигураций. Начиная с vCenter 9.0, функциональность Host Profiles объявлена устаревшей и будет полностью удалена в будущих версиях.
  
  Рекомендация: вместо Host Profiles используйте vSphere Configuration Profiles, позволяющие управлять настройками на уровне кластера. Новый подход интегрирован с жизненным циклом vLCM и обеспечит более надежную и простую поддержку конфигураций.

• vSphere ESX Image Builder (устарела) – инструмент для создания кастомных образов ESXi (добавления драйверов и VIB-пакетов) больше не развивается. Функциональность Image Builder фактически поглощена возможностями vSphere Lifecycle Manager (vLCM): в vSphere 9 вы можете создавать библиотеку образов ESX на уровне vCenter и собирать желаемый образ из компонентов (драйверов, надстроек от вендоров и т.д.) прямо в vCenter.
  
  Рекомендация: для формирования образов ESXi используйте vLCM Desired State Images и новую функцию ESX Image Library в vCenter 9, которая позволит единообразно управлять образами для кластеров вместо ручной сборки ISO-файлов.

• vSphere Virtual Volumes (vVols, устарела) – технология виртуальных томов хранения объявлена устаревшей с выпуском VCF 9.0 / vSphere 9.0. Поддержка vVols отныне будет осуществляться только для критических исправлений в vSphere 8.x (VCF 5.x) до конца их поддержки. В VCF/VVF 9.1 функциональность vVols планируется полностью удалить.
  
  Рекомендация: если в вашей инфраструктуре используются хранилища на основе vVols, следует подготовиться к миграции виртуальных машин на альтернативные хранилища. Предпочтительно задействовать VMFS или vSAN, либо проверить у вашего поставщика СХД доступность поддержки vVols в VCF 9.0 (в индивидуальном порядке возможна ограниченная поддержка, по согласованию с Broadcom). В долгосрочной перспективе стратегия VMware явно смещается в сторону vSAN и NVMe, поэтому использование vVols нужно минимизировать.

• vCenter Enhanced Linked Mode (устарела) – расширенный связанный режим vCenter (ELM), позволявший объединять несколько vCenter Server в единый домен SSO с общей консолью, более не используется во VCF 9. В vCenter 9.0 ELM объявлен устаревшим и будет удалён в будущих версиях. Хотя поддержка ELM сохраняется в версии 9 для возможности обновления существующих инфраструктур, сама архитектура VCF 9 переходит на иной подход: единое управление несколькими vCenter осуществляется средствами VCF Operations вместо связанного режима.
  
  Рекомендация: при планировании VCF 9 откажитесь от развёртывания новых связанных групп vCenter. После обновления до версии 9 рассмотрите перевод существующих vCenter из ELM в раздельный режим с группированием через VCF Operations (который обеспечивает центральное управление без традиционного ELM). Функции, ранее обеспечивавшиеся ELM (единый SSO, объединённые роли, синхронизация тегов, общая точка API и пр.), теперь достигаются за счёт возможностей VCF Operations и связанных сервисов.

• vSphere Clustering Service (vCLS, устарела) – встроенный сервис кластеризации, который с vSphere 7 U1 запускал небольшие служебные ВМ (vCLS VMs) для поддержки DRS и HA, в vSphere 9 более не нужен. В vCenter 9.0 сервис vCLS помечен устаревшим и подлежит удалению в будущем. Кластеры vSphere 9 могут работать без этих вспомогательных ВМ: после обновления появится возможность включить Retreat Mode и отключить развёртывание vCLS-агентов без какого-либо ущерба для функциональности DRS/HA.
  
  Рекомендация: отключите vCLS на кластерах vSphere 9 (включив режим Retreat Mode в настройках кластера) – деактивация vCLS никак не влияет на работу DRS и HA. Внутри ESX 9 реализовано распределенное хранилище состояния кластера (embedded key-value store) непосредственно на хостах, благодаря чему кластер может сохранять и восстанавливать свою конфигурацию без внешних вспомогательных ВМ. В результате вы упростите окружение (больше никаких «мусорных» служебных ВМ) и избавитесь от связанных с ними накладных расходов.

• ESX Host Cache (устарела) - в версии ESX 9.0 использование кэша на уровне хоста (SSD) в качестве кэша с обратной записью (write-back) для файлов подкачки виртуальных машин (swap) объявлено устаревшим и будет удалено в одной из будущих версий. В качестве альтернативы предлагается использовать механизм многоуровневой памяти (Memory Tiering) на базе NVMe. Memory Tiering с NVMe позволяет увеличить объём доступной оперативной памяти на хосте и интеллектуально распределять память виртуальной машины между быстрой динамической оперативной памятью (DRAM) и NVMe-накопителем на хосте.
  
  Рекомендация: используйте функции Advanced Memory Tiering на базе NVMe-устройств в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогого оборудования.
  
  
• Память Intel Optane Persistent Memory (удалена) - в версии ESX 9.0 прекращена поддержка технологии Intel Optane Persistent Memory (PMEM). Для выбора альтернативных решений обратитесь к представителям вашего OEM-поставщика серверного оборудования.
  
  Рекомендация: в качестве альтернативы вы можете использовать функционал многоуровневой памяти (Memory Tiering), официально представленный в ESX 9.0. Эта технология позволяет добавлять локальные NVMe-устройства на хост ESX в качестве дополнительного уровня памяти. Дополнительные подробности смотрите в статье базы знаний VMware KB 326910.
  
  
• Технология Storage I/O Control (SIOC) и балансировщик нагрузки Storage DRS (удалены) - в версии vCenter 9.0 прекращена поддержка балансировщика нагрузки Storage DRS (SDRS) на основе ввода-вывода (I/O Load Balancer), балансировщика SDRS на основе резервирования ввода-вывода (SDRS I/O Reservations-based load balancer), а также компонента vSphere Storage I/O Control (SIOC). Эти функции продолжают поддерживаться в текущих релизах 8.x и 7.x. Удаление указанных компонентов затрагивает балансировку нагрузки на основе задержек ввода-вывода (I/O latency-based load balancing) и балансировку на основе резервирования ввода-вывода (I/O reservations-based load balancing) между хранилищами данных (datastores), входящими в кластер хранилищ Storage DRS. Кроме того, прекращена поддержка активации функции Storage I/O Control (SIOC) на отдельном хранилище и настройки резервирования (Reservations) и долей (Shares) с помощью политик хранения SPBM Storage Policy. При этом первоначальное размещение виртуальных машин с помощью Storage DRS (initial placement), а также балансировка нагрузки на основе свободного пространства и политик SPBM Storage Policy (для лимитов) не затронуты и продолжают работать в vCenter 9.0.
  
  Рекомендация: администраторам рекомендуется нужно перейти на балансировку нагрузки на основе свободного пространства и политик SPBM. Настройки резервирований и долей ввода-вывода (Reservations, Shares) через SPBM следует заменить альтернативными механизмами контроля производительности со стороны используемых систем хранения (например, встроенными функциями QoS). После миграции необходимо обеспечить мониторинг производительности, чтобы своевременно устранять возможные проблемы.
  
  
• vSphere Lifecycle Manager Baselines (удалена) – классический режим управления патчами через базовые уровни (baselines) в vSphere 9 не поддерживается. Начиная с vCenter 9.0 полностью удалён функционал VUM/vLCM Baselines – все кластеры и хосты должны использовать только рабочий процесс управления жизненным циклом на базе образов (image-based lifecycle). При обновлении с vSphere 8 имеющиеся кластеры на baselines придётся перевести на работу с образами, прежде чем поднять их до ESX 9.
  
  Рекомендация: перейдите от использования устаревших базовых уровней к vLCM images – желаемым образам кластера. vSphere 9 позволяет применять один образ к нескольким кластерам или хостам сразу, управлять соответствием (compliance) и обновлениями на глобальном уровне. Это упростит администрирование и устранит необходимость в ручном создании и применении множества baseline-профилей.
  
  
• Integrated Windows Authentication (IWA, удалена) – в vCenter 9.0 прекращена поддержка интегрированной Windows-аутентификации (прямого добавления vCenter в домен AD). Вместо IWA следует использовать LDAP(S) или федерацию. VMware официально заявляет, что vCenter 9.0 более не поддерживает IWA, и для обеспечения безопасного доступа необходимо мигрировать учетные записи на Active Directory over LDAPS или настроить федерацию (например, через ADFS) с многофакторной аутентификацией.
  
  Рекомендация: до обновления vCenter отключите IWA, переведите интеграцию с AD на LDAP(S), либо настройте VMware Identity Federation с MFA (эта возможность появилась начиная с vSphere 7). Это позволит сохранить доменную интеграцию vCenter в безопасном режиме после перехода на версию 9.
  
  
• Локализации интерфейса (сокращены) – В vSphere 9 уменьшено число поддерживаемых языков веб-интерфейса. Если ранее vCenter поддерживал множество языковых пакетов, то в версии 9 оставлены лишь английский (US) и три локали: японский, испанский и французский. Все остальные языки (включая русский) более недоступны.
  
  Рекомендация: администраторы, использующие интерфейс vSphere Client на других языках, должны быть готовы работать на английском либо на одной из трёх оставшихся локалей. Учебные материалы и документацию стоит ориентировать на английскую версию интерфейса, чтобы избежать недопонимания.

Общий совет по миграции для vSphere: заранее инвентаризуйте использование перечисленных функций в вашей инфраструктуре. Переход на vSphere 9 – удобный повод внедрить новые подходы: заменить Host Profiles на Configuration Profiles, перейти от VUM-бейзлайнов к образам, отказаться от ELM в пользу новых средств управления и т.д. Благодаря этому обновление пройдет более гладко, а ваша платформа будет соответствовать современным рекомендациям VMware.

Мы привели, конечно же, список только самых важных функций VMware vSphere 9, которые подверглись устареванию или удалению, для получения полной информации обратитесь к этой статье Broadcom.

VMware NSX 9: Устаревшие и неподдерживаемые функции

VMware NSX 9.0 (ранее известный как NSX-T) – компонент виртуализации сети в составе VCF 9 – также претерпел существенные изменения. Новая версия NSX ориентирована на унифицированную работу с VMware Cloud Foundation и отказывается от ряда старых возможностей, особенно связанных с гибкостью поддержки разных платформ. Вот ключевые технологии, не поддерживаемые больше в NSX 9, и как к этому адаптироваться:

• Подключение физических серверов через NSX-Agent (удалено) – В NSX 9.0 больше не поддерживается развёртывание NSX bare-metal agent на физических серверах для включения их в оверлей NSX. Ранее такие агенты позволяли физическим узлам участвовать в логических сегментах NSX (оверлейных сетях). Начиная с версии 9, оверлейная взаимосвязь с физическими серверами не поддерживается – безопасность для физических серверов (DFW) остаётся, а вот L2-overlay connectivity убрана.
  
  Рекомендация: для подключения физических нагрузок к виртуальным сетям NSX теперь следует использовать L2-мосты (bridge) на NSX Edge. VMware прямо рекомендует для новых подключений физических серверов задействовать NSX Edge bridging для обеспечения L2-связности с оверлеем, вместо установки агентов на сами серверы. То есть физические серверы подключаются в VLAN, который бриджится в логический сегмент NSX через Edge Node. Это позволяет интегрировать физическую инфраструктуру с виртуальной без установки NSX компонентов на сами серверы. Если у вас были реализованы bare-metal transport node в старых версиях NSX-T 3.x, их придётся переработать на схему с Edge-бриджами перед обновлением до NSX 9. Примечание: распределённый мост Distributed TGW, появившийся в VCF 9, также может обеспечить выход ВМ напрямую на ToR без Edge-узла, что актуально для продвинутых случаев, но базовый подход – через Edge L2 bridge.

• Виртуальный коммутатор N-VDS на ESXi (удалён) – исторически NSX-T использовала собственный виртуальный коммутатор N-VDS для хостов ESXi и KVM. В NSX 9 эта технология более не применяется для ESX-хостов. Поддержка NSX N-VDS на хостах ESX удалена, начиная с NSX 4.0.0.1 (соответствует VCF 9). Теперь NSX интегрируется только с родным vSphere Distributed Switch (VDS) версии 7.0 и выше. Это означает, что все среды на ESX должны использовать конвергентный коммутатор VDS для работы NSX. N-VDS остаётся лишь в некоторых случаях: на Edge-нодах и для агентов в публичных облаках или на bare-metal Linux (где нет vSphere), но на гипервизорах ESX – больше нет.
  
  Рекомендация: перед обновлением до NSX 9 мигрируйте все транспортные узлы ESXi с N-VDS на VDS. VMware предоставила инструменты миграции host switch (начиная с NSX 3.2) – ими следует воспользоваться, чтобы перевести существующие NSX-T 3.x host transport nodes на использование VDS. После перехода на NSX 9 вы получите более тесную интеграцию сети с vCenter и упростите управление, так как сетевые политики NSX привязываются к стандартному vSphere VDS. Учтите, что NSX 9 требует наличия vCenter для настройки сетей (фактически NSX теперь не работает автономно от vSphere), поэтому планируйте инфраструктуру исходя из этого.

• Поддержка гипервизоров KVM и стороннего OpenStack (удалена) – NSX-T изначально позиционировался как мультигипервизорное решение, поддерживая кроме vSphere также KVM (Linux) и интеграцию с opensource OpenStack. Однако с выходом NSX 4.0 (и NSX 9) стратегия изменилась. NSX 9.0 больше не поддерживает гипервизоры KVM и дистрибутивы OpenStack от сторонних производителей. Поддерживается лишь VMware Integrated OpenStack (VIO) как исключение. Проще говоря, NSX сейчас нацелен исключительно на экосистему VMware.
  
  Рекомендация: если у вас были развёрнуты политики NSX на KVM-хостах или вы использовали NSX-T совместно с не-VMware OpenStack, переход на NSX 9 невозможен без изменения архитектуры. Вам следует либо остаться на старых версиях NSX-T 3.x для таких сценариев, либо заменить сетевую виртуализацию в этих средах на альтернативные решения. В рамках же VCF 9 такая ситуация маловероятна, так как VCF подразумевает vSphere-стек. Таким образом, основное действие – убедиться, что все рабочие нагрузки NSX переведены на vSphere, либо изолировать NSX-T 3.x для специфичных нужд вне VCF. В будущем VMware будет развивать NSX как часть единой платформы, поэтому мультиплатформенные возможности урезаны в пользу оптимизации под vSphere.

• NSX for vSphere (NSX-V) 6.x – не применяется – отдельно стоит упомянуть, что устаревшая платформа NSX-V (NSX 6.x для vSphere) полностью вышла из обращения и не входит в состав VCF 9. Её поддержка VMware прекращена еще в начале 2022 года, и миграция на NSX-T (NSX 4.x) стала обязательной. В VMware Cloud Foundation 4.x и выше NSX-V отсутствует, поэтому для обновления окружения старше VCF 3 потребуется заранее выполнить миграцию сетевой виртуализации на NSX-T.
  
  Рекомендация: если вы ещё используете NSX-V в старых сегментах, необходимо развернуть параллельно NSX 4.x (NSX-T) и перенести сетевые политики и сервисы (можно с помощью утилиты Migration Coordinator, если поддерживается ваша версия). Только после перехода на NSX-T вы сможете обновиться до VCF 9. В новой архитектуре все сетевые функции будут обеспечиваться NSX 9, а NSX-V останется в прошлом.

Подводя итог по NSX: VMware NSX 9 сфокусирован на консолидации функций для частных облаков на базе vSphere. Возможности, выходящие за эти рамки (поддержка разнородных гипервизоров, агенты на физической базе и др.), были убраны ради упрощения и повышения производительности. Администраторам следует заранее учесть эти изменения: перевести сети на VDS, пересмотреть способы подключения физических серверов и убедиться, что все рабочие нагрузки, требующие NSX, работают в поддерживаемой конфигурации. Благодаря этому переход на VCF 9 будет предсказуемым, а новая среда – более унифицированной, безопасной и эффективной. Подготовившись к миграции от устаревших технологий на современные аналоги, вы сможете реализовать преимущества VMware Cloud Foundation 9.0 без длительных простоев и с минимальным риском для работы дата-центра.

Итоги

Большинство приведённых выше изменений официально перечислены в документации Product Support Notes к VMware Cloud Foundation 9.0 для vSphere и NSX. Перед обновлением настоятельно рекомендуется внимательно изучить примечания к выпуску и убедиться, что ни одна из устаревших функций, на которых зависит ваша инфраструктура, не окажется критичной после перехода. Следуя рекомендациям по переходу на новые инструменты (vLCM, Configuration Profiles, Edge Bridge и т.д.), вы обеспечите своей инфраструктуре поддерживаемость и готовность к будущим обновлениям в экосистеме VMware Cloud Foundation.

Итак, наконец-то начинаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 9, которая является основой пакета решений VMware Cloud Foundation 9, о релизе которого компания Broadcom объявила несколько дней назад. Самое интересное - гипервизор теперь опять называется ESX, а не ESXi, который также стал последователем ESX в свое время :)

Управление жизненным циклом

Путь обновления vSphere

vSphere 9.0 поддерживает прямое обновление только с версии vSphere 8.0. Прямое обновление с vSphere 7.0 не поддерживается. vCenter 9.0 не поддерживает управление ESX 7.0 и более ранними версиями. Минимально поддерживаемая версия ESX, которую может обслуживать vCenter 9.0, — это ESX 8.0. Кластеры и отдельные хосты, управляемые на основе baseline-конфигураций (VMware Update Manager, VUM), не поддерживаются в vSphere 9. Кластеры и хосты должны использовать управление жизненным циклом только на основе образов.

Live Patch для большего числа компонентов ESX

Функция Live Patch теперь охватывает больше компонентов образа ESX, включая vmkernel и компоненты NSX. Это увеличивает частоту применения обновлений без перезагрузки. Компоненты NSX, теперь входящие в базовый образ ESX, можно обновлять через Live Patch без перевода хостов в режим обслуживания и без необходимости эвакуировать виртуальные машины.

Компоненты vmkernel, пользовательское пространство, vmx (исполнение виртуальных машин) и NSX теперь могут использовать Live Patch. Службы ESX (например, hostd) могут потребовать перезапуска во время применения Live Patch, что может привести к кратковременному отключению хостов ESX от vCenter. Это ожидаемое поведение и не влияет на работу запущенных виртуальных машин. vSphere Lifecycle Manager сообщает, какие службы или демоны будут перезапущены в рамках устранения уязвимостей через Live Patch. Если Live Patch применяется к среде vmx (исполнение виртуальных машин), запущенные ВМ выполнят быструю приостановку и восстановление (Fast-Suspend-Resume, FSR).

Live Patch совместим с кластерами vSAN. Однако узлы-свидетели vSAN (witness nodes) не поддерживают Live Patch и будут полностью перезагружаться при обновлении. Хосты, использующие TPM и/или DPU-устройства, в настоящее время не совместимы с Live Patch.

Создавайте кластеры по-своему с разным оборудованием

vSphere Lifecycle Manager поддерживает кластеры с оборудованием от разных производителей, а также работу с несколькими менеджерами поддержки оборудования (hardware support managers) в рамках одного кластера. vSAN также поддерживает кластеры с различным оборудованием.

Базовая версия ESX является неизменной для всех дополнительных образов и не может быть настроена. Однако надстройки от производителей (vendor addon), прошивка и компоненты в определении каждого образа могут быть настроены индивидуально для поддержки кластеров с разнородным оборудованием. Каждое дополнительное определение образа может быть связано с уникальным менеджером поддержки оборудования (HSM).

Дополнительные образы можно назначать вручную для подмножества хостов в кластере или автоматически — на основе информации из BIOS, включая значения Vendor, Model, OEM String и Family. Например, можно создать кластер, состоящий из 5 хостов Dell и 5 хостов HPE: хостам Dell можно назначить одно определение образа с надстройкой от Dell и менеджером Dell HSM, а хостам HPE — другое определение образа с надстройкой от HPE и HSM от HPE.

Масштабное управление несколькими образами

Образами vSphere Lifecycle Manager и их привязками к кластерам или хостам можно управлять на глобальном уровне — через vCenter, датацентр или папку. Одно определение образа может применяться к нескольким кластерам и/или отдельным хостам из единого централизованного интерфейса. Проверка на соответствие (Compliance), предварительная проверка (Pre-check), подготовка (Stage) и устранение (Remediation) также могут выполняться на этом же глобальном уровне.

Существующие кластеры и хосты с управлением на основе базовых конфигураций (VUM)

Существующие кластеры и отдельные хосты, работающие на ESX 8.x и использующие управление на основе базовых конфигураций (VUM), могут по-прежнему управляться через vSphere Lifecycle Manager, но для обновления до ESX 9 их необходимо перевести на управление на основе образов. Новые кластеры и хосты не могут использовать управление на основе baseline-конфигураций, даже если они работают на ESX 8. Новые кластеры и хосты автоматически используют управление жизненным циклом на основе образов.

Больше контроля над операциями жизненного цикла кластера

При устранении проблем (remediation) в кластерах теперь доступна новая возможность — применять исправления к подмножеству хостов в виде пакета. Это дополняет уже существующие варианты — обновление всего кластера целиком или одного хоста за раз.

Гибкость при выборе хостов для обновления

Описанные возможности дают клиентам гибкость — можно выбрать, какие хосты обновлять раньше других. Другой пример использования — если в кластере много узлов и обновить все за одно окно обслуживания невозможно, клиенты могут выбирать группы хостов и обновлять их поэтапно в несколько окон обслуживания.

Больше никакой неопределённости при обновлениях и патчах

Механизм рекомендаций vSphere Lifecycle Manager учитывает версию vCenter. Версия vCenter должна быть равной или выше целевой версии ESX. Например, если vCenter работает на версии 9.1, механизм рекомендаций не предложит обновление хостов ESX до 9.2, так как это приведёт к ситуации, где хосты будут иметь более новую версию, чем vCenter — что не поддерживается. vSphere Lifecycle Manager использует матрицу совместимости продуктов Broadcom VMware (Product Interoperability Matrix), чтобы убедиться, что целевой образ ESX совместим с текущей средой и поддерживается.

Упрощённые определения образов кластера

Компоненты vSphere HA и NSX теперь встроены в базовый образ ESX. Это делает управление их жизненным циклом и обеспечением совместимости более прозрачным и надёжным. Компоненты vSphere HA и NSX автоматически обновляются вместе с установкой патчей или обновлений базового образа ESX. Это ускоряет активацию NSX на кластерах vSphere, поскольку VIB-пакеты больше не требуется отдельно загружать и устанавливать через ESX Agent Manager (EAM).

Определение и применение конфигурации NSX для кластеров vSphere с помощью vSphere Configuration Profiles

Теперь появилась интеграция NSX с кластерами, управляемыми через vSphere Configuration Profiles. Профили транспортных узлов NSX (TNP — Transport Node Profiles) применяются с использованием vSphere Configuration Profiles. vSphere Configuration Profiles позволяют применять TNP к кластеру одновременно с другими изменениями конфигурации.

Применение TNP через NSX Manager отключено для кластеров с vSphere Configuration Profiles

Для кластеров, использующих vSphere Configuration Profiles, возможность применять TNP (Transport Node Profile) через NSX Manager отключена. Чтобы применить TNP с помощью vSphere Configuration Profiles, необходимо также задать:

• набор правил брандмауэра с параметром DVFilter=true
• настройку Syslog с параметром remote_host_max_msg_len=4096

Снижение рисков и простоев при обновлении vCenter

Функция Reduced Downtime Update (RDU) поддерживается при использовании установщика на базе CLI. Также доступны RDU API для автоматизации. RDU поддерживает как вручную настроенные топологии vCenter HA, так и любые другие топологии vCenter. RDU является рекомендуемым способом обновления, апгрейда или установки патчей для vCenter 9.0.

Обновление vCenter с использованием RDU можно выполнять через vSphere Client, CLI или API. Интерфейс управления виртуальным устройством (VAMI) и соответствующие API для патчинга также могут использоваться для обновлений без переустановки или миграции, однако при этом потребуется значительное время простоя.

Сетевые настройки целевой виртуальной машины vCenter поддерживают автоматическую конфигурацию, упрощающую передачу данных с исходного vCenter. Эта сеть автоматически настраивается на целевой и исходной виртуальных машинах vCenter с использованием адреса из диапазона Link-Local RFC3927 169.254.0.0/16. Это означает, что не требуется указывать статический IP-адрес или использовать DHCP для временной сети.

Этап переключения (switchover) может выполняться вручную, автоматически или теперь может быть запланирован на конкретную дату и время в будущем.

Управление ресурсами

Масштабирование объема памяти с более низкой стоимостью владения благодаря Memory Tiering с использованием NVMe

Memory Tiering использует устройства NVMe на шине PCIe как второй уровень оперативной памяти, что увеличивает доступный объем памяти на хосте ESX. Memory Tiering на базе NVMe снижает общую стоимость владения (TCO) и повышает плотность размещения виртуальных машин, направляя память ВМ либо на устройства NVMe, либо на более быструю оперативную память DRAM.

Это позволяет увеличить объем доступной памяти и количество рабочих нагрузок, одновременно снижая TCO. Также повышается эффективность использования процессорных ядер и консолидация серверов, что увеличивает плотность размещения рабочих нагрузок.

Функция Memory Tiering теперь доступна в производственной среде. В vSphere 8.0 Update 3 функция Memory Tiering была представлена в режиме технологического превью. Теперь же она стала доступна в режиме GA (General Availability) с выпуском VCF 9.0. Это позволяет использовать локально установленные устройства NVMe на хостах ESX как часть многоуровневой (tiered) памяти.

Повышенное время безотказной работы для AI/ML-нагрузок

Механизм Fast-Suspend-Resume (FSR) теперь работает значительно быстрее для виртуальных машин с поддержкой vGPU. Ранее при использовании двух видеокарт NVIDIA L40 с 48 ГБ памяти каждая, операция FSR занимала около 42 секунд. Теперь — всего около 2 секунд. FSR позволяет использовать Live Patch в кластерах, обрабатывающих задачи генеративного AI (Gen AI), без прерывания работы виртуальных машин.

Передача данных vGPU с высокой пропускной способностью

Канал передачи данных vGPU разработан для перемещения больших объемов данных и построен с использованием нескольких параллельных TCP-соединений и автоматического масштабирования до максимально доступной пропускной способности канала, обеспечивая прирост скорости до 3 раз (с 10 Гбит/с до 30 Гбит/с).

Благодаря использованию концепции "zero copy" количество операций копирования данных сокращается вдвое, устраняя узкое место, связанное с копированием, и дополнительно увеличивая пропускную способность при передаче.

vMotion с предкопированием (pre-copy) — это технология передачи памяти виртуальной машины на другой хост с минимальным временем простоя. Память виртуальной машины (как "холодная", так и "горячая") копируется в несколько проходов пока ВМ ещё работает, что устраняет необходимость полного чекпойнта и передачи всей памяти во время паузы, во время которой случается простой сервисов.

Улучшения в предкопировании холодных данных могут зависеть от характера нагрузки. Например, для задачи генеративного AI с большим объёмом статических данных ожидаемое время приостановки (stun-time) будет примерно:

• ~1 секунда для GPU-нагрузки объёмом 24 ГБ
• ~2 секунды для 48 ГБ
• ~22 секунды для крупной 640 ГБ GPU-нагрузки

Отображение профилей vGPU в vSphere DRS

Технология vGPU позволяет распределять физический GPU между несколькими виртуальными машинами, способствуя максимальному использованию ресурсов видеокарты.
В организациях с большим числом GPU со временем создаётся множество vGPU-профилей. Однако администраторы не могут легко просматривать уже созданные vGPU, что вынуждает их вручную отслеживать профили и их распределение по GPU. Такой ручной процесс отнимает время и снижает эффективность работы администраторов.

Отслеживание использования vGPU-профилей позволяет администраторам просматривать все vGPU во всей инфраструктуре GPU через удобный интерфейс в vCenter, устраняя необходимость ручного учёта vGPU. Это существенно сокращает время, затрачиваемое администраторами на управление ресурсами.

В предыдущих версиях распределение виртуальных машин с vGPU могло приводить к ситуации, при которой ни один из хостов не мог удовлетворить требования нового профиля vGPU. Теперь же администраторы могут резервировать ресурсы GPU для будущего использования. Это позволяет заранее выделить GPU-ресурсы, например, для задач генеративного AI, что помогает избежать проблем с производительностью при развертывании таких приложений. С появлением этой новой функции администраторы смогут резервировать пулы ресурсов под конкретные vGPU-профили заранее, улучшая планирование ресурсов и повышая производительность и операционную эффективность.

Администраторы теперь могут перемещать существующие библиотеки контента на новые хранилища данных (datastore) - OVF/OVA-шаблоны, образы и другие элементы могут быть перенесены. Элементы, хранящиеся в формате VM Template (VMTX), не переносятся в целевой каталог библиотеки контента. Шаблоны виртуальных машин (VM Templates) всегда остаются в своем назначенном хранилище, а в библиотеке контента хранятся только ссылки на них.

Во время миграции библиотека контента перейдёт в режим обслуживания, а после завершения — снова станет активной. На время миграции весь контент библиотеки (за исключением шаблонов ВМ) будет недоступен. Изменения в библиотеке будут заблокированы, синхронизация с подписными библиотеками приостановлена.

Служба виртуальных машин (VM Service) теперь может импортировать виртуальные машины, находящиеся за пределами Supervisor-кластера, и взять их под своё управление.

В vSphere 8 был представлен протокол Unified Data Transport (UDT) для "холодной" миграции дисков, ранее выполнявшейся с использованием NFC. UDT значительно ускоряет холодную миграцию, но вместе с повышенной эффективностью увеличивается и нагрузка на сеть предоставления ресурсов (provisioning network), которая в текущей архитектуре использует общий канал с критически важным трафиком управления.

Чтобы предотвратить деградацию трафика управления, необходимо использовать Network I/O Control (NIOC) — он позволяет гарантировать приоритет управления даже при высокой сетевой нагрузке.

vSphere Distributed Switch 9 добавляет отдельную категорию системного трафика для provisioning, что позволяет применять настройки NIOC и обеспечить баланс между производительностью и стабильностью.

Provisioning/NFC-трафик (включая Network File Copy) является тяжеловесным и низкоприоритетным, но при этом использует ту же категорию трафика, что и управляющий (management), который должен быть легковесным и высокоприоритетным. С учетом того, что трафик provisioning/NFC стал ещё более агрессивным с внедрением NFC SOV (Streaming Over vMotion), вопрос времени, когда критически важный трафик управления начнёт страдать.

Существует договоренность с VCF: как только NIOC для provisioning/NFC будет реализован, можно будет включать NFC SOV в развёртываниях VCF. Это ускорит внедрение NFC SOV в продуктивных средах.

Устройства, которые не могут быть приостановлены (non-stunnable devices), теперь поддерживают Storage vMotion (но не обычный vMotion), а также горячее добавление виртуальных устройств, таких как:

• vCPU
• Память (Memory)
• Сетевые адаптеры (NIC)

Примеры non-stunnable устройств:

• Intel DLB (Dynamic Load Balancer)
• AMD MI200 GPU

Гостевые ОС и рабочие нагрузки

Виртуальное оборудование версии 22 (Virtual Hardware Version 22)

• Увеличен лимит vCPU до 960 на одну виртуальную машину
• Поддержка новейших моделей процессоров от AMD и Intel
• Поддержка новых версий гостевых ОС для развертывания ВМ (см. Guest OS Support в VCF 9.0)

Виртуальный модуль доверенной платформы (vTPM)

• vTPM теперь поддерживает спецификацию TPM 2.0, версия 1.59.
• ESX 9.0 соответствует TPM 2.0 Rev 1.59.
• Это повышает уровень кибербезопасности, когда вы добавляете vTPM-устройство в виртуальную машину с версией 22 виртуального железа.

Новые vAPI для настройки гостевых систем (Guest Customization)

Представлен новый интерфейс CustomizationLive API, который позволяет применять спецификацию настройки (customization spec) к виртуальной машине в работающем состоянии (без выключения). Подробности — в последней документации по vSphere Automation API для VCF 9.0. Также добавлен новый API для настройки гостевых систем, который позволяет определить, можно ли применить настройку к конкретной ВМ, ещё до её применения.

• Namespace Write Protection - позволяет горячее добавление независимых непостоянных (non-persistent) дисков в виртуальную машину без создания дополнительных delta-дисков. Эта функция особенно полезна для рабочих нагрузок, которым требуется быстрое развёртывание приложений.
• Write Zeros - для виртуальных NVMe-дисков улучшает производительность, эффективность хранения данных и дает возможности управления данными для различных типов нагрузок.

Безопасность, соответствие требованиям и отказоустойчивость виртуальных машин

Одним из частых запросов в последние годы была возможность использовать собственные сертификаты Secure Boot для ВМ. Обычно виртуальные машины работают "из коробки" с коммерческими ОС, но некоторые организации используют собственные ядра Linux и внутреннюю PKI-инфраструктуру для их подписи.

Теперь появилась прямая и удобная поддержка такой конфигурации — vSphere предоставляет механизм для загрузки виртуальных машин с кастомными сертификатами Secure Boot.

Обновлён список отозванных сертификатов Secure Boot

VMware обновила стандартный список отозванных сертификатов Secure Boot, поэтому при установке Windows на виртуальную машину с новой версией виртуального оборудования может потребоваться современный установочный образ Windows от Microsoft. Это не критично, но стоит иметь в виду, если установка вдруг не загружается.

Виртуальный USB — отличная функция, но VMware внесла ряд улучшений на основе отчётов исследователей по безопасности. Это ещё один веский аргумент в пользу того, чтобы поддерживать актуальность VMware Tools и версий виртуального оборудования.

Обычно мы стремимся к тому, чтобы снапшот ВМ можно было запустить повторно и обеспечить согласованность при сбое (crash-consistency), то есть чтобы система выглядела как будто питание отключилось. Большинство ОС, СУБД и приложений умеют с этим справляться.

Но в случае цифровой криминалистики и реагирования на инциденты, необходимость перезапускать ВМ заново отпадает — важнее получить снимок, пригодный для анализа в специальных инструментах.

Теперь вы можете создавать собственный профиль EVC (Enhanced vMotion Compatibility), определяя набор CPU- и графических инструкций, общих для всех выбранных хостов. Это решение более гибкое и динамичное, чем стандартные предустановленные профили EVC.

Custom EVC позволяет:

• Указать хосты и/или кластеры, для которых vCenter сам рассчитает максимально возможный общий набор инструкций
• Применять полученный профиль к кластерам или отдельным ВМ

Для работы требуется vCenter 9.0 и поддержка кластеров, содержащих хосты ESX 9.0 или 8.0. Теперь доступно более эффективное использование возможностей CPU при различиях между моделями - можно полнее использовать функции процессоров, даже если модели немного отличаются. Пример: два процессора одного поколения, но разных вариантов:

• CPU-1 содержит функции A, B, D, E, F
• CPU-2 содержит функции B, C, D, E, F
• То есть: CPU-1 поддерживает FEATURE-A, но не FEATURE-C, CPU-2 — наоборот.

Custom EVC позволяет автоматически выбрать максимальный общий набор функций, доступный на всех хостах, исключая несовместимости:

В vSphere 9 появилась новая политика вычислений: «Limit VM placement span plus one host for maintenance» («ограничить размещение ВМ числом хостов плюс один для обслуживания»).

Эта политика упрощает соблюдение лицензионных требований и контроль использования лицензий. Администраторы теперь могут создавать политики на основе тегов, которые жестко ограничивают количество хостов, на которых может запускаться группа ВМ с лицензируемым приложением.

Больше не нужно вручную закреплять ВМ за хостами или создавать отдельные кластеры/хосты. Теперь администратору нужно просто:

1. Знать, сколько лицензий куплено.
2. Знать, на скольких хостах они могут применяться.
3. Создать политику с указанием числа хостов, без выбора конкретных.
4. Применить эту политику к ВМ с нужным тегом.

vSphere сама гарантирует, что такие ВМ смогут запускаться только на разрешённом числе хостов. Всегда учитывается N+1 хост в запас для обслуживания. Ограничение динамическое — не привязано к конкретным хостам.

Полный список новых возможностей VMware vSphere 9 также приведен в Release Notes.

Многоуровневая память (Memory Tiering) снижает затраты и повышает эффективность использования ресурсов. Эта функция была впервые представлена в виде технологического превью в vSphere 8.0 Update 3 и получила очень положительные отзывы от клиентов. Обратная связь от пользователей касалась в основном устойчивости данных, безопасности и гибкости в конфигурациях хостов и виртуальных машин. С выходом платформы VCF 9.0 все эти вопросы были решены.

Теперь многоуровневая память — это готовое к использованию в производственной среде решение, включающее поддержку DRS и vMotion, повышенную производительность, улучшенное соотношение DRAM:NVMe по умолчанию (1:1), а также множество других улучшений, направленных на повышение надёжности этой функции.

В компании Broadcom было проведено масштабное внутреннее тестирование, которое показало, что использование многоуровневой памяти позволяет сократить совокупную стоимость владения (TCO) до 40% для большинства рабочих нагрузок, а также обеспечивает рост загрузки CPU, позволяя использовать на 25–30% больше ядер под задачи. Меньше затрат — больше ресурсов. Кроме того, лучшая консолидация ВМ может означать меньше серверов или больше ВМ на каждом сервере.

Многоуровневая память обеспечивает все эти и многие другие преимущества, используя NVMe-устройства в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогих устройств, таких как NVMe. Между предварительной технической версией и готовым к промышленному использованию выпуском с VCF 9.0 существует множество важных отличий. Давайте рассмотрим эти улучшения.

Новые возможности Advanced Memory Tiering

Смешанный кластер

Многоуровневая память (Memory Tiering) может быть настроена на всех хостах в кластере, либо вы можете включить эту функцию только для части хостов. Причины для этого могут быть разными: например, вы хотите протестировать технологию на одном хосте и нескольких ВМ, возможно, только несколько хостов имеют свободные слоты для NVMe-устройств, или вам разрешили приобрести лишь ограниченное количество накопителей. Хорошая новость в том, что поддерживаются все эти и многие другие сценарии — чтобы соответствовать текущим возможностям заказчиков. Вы можете выбрать только часть хостов или активировать эту функцию на всех.

Резервирование

Резервирование всегда является приоритетом при проектировании архитектуры. Как вы знаете, не бывает серьезной производственной среды с одной единственной сетевой картой на сервер. Что касается накопителей, то обеспечить отказоустойчивость можно с помощью конфигурации RAID — именно это и было реализовано. Многоуровневая память может использовать два и более NVMe-устройств в аппаратной RAID-конфигурации для защиты от отказов устройств.

Поддержка DRS

Технология DRS (Distributed Resource Scheduler) существует уже довольно давно, это одна из функций, без которой большинство клиентов уже не могут обходиться. VMware вложила много усилий в то, чтобы сделать алгоритм Memory Tiering «умным» — чтобы он не только анализировал состояние страниц памяти, но и эффективно управлял ими в пределах кластера.

DRAM:NVMe — новое соотношение

В vSphere 8.0 U3 функция Memory Tiering была представлена как технологическое превью. Тогда использовалось соотношение 4:1, то есть на 4 части DRAM приходилась 1 часть NVMe. Это дало увеличение объёма памяти на 25%. Хотя это может показаться незначительным, при сравнении стоимости увеличения объёма памяти на 25% с использованием DRAM и NVMe становится очевидно, насколько это выгодно.

В VCF 9.0, после всех улучшений производительности, изменили соотношение по умолчанию: теперь оно 1:1 — то есть увеличение объема памяти в 2 раза по умолчанию. И это значение можно настраивать в зависимости от нагрузки и потребностей. То есть, если у вас есть хост ESX с 1 ТБ DRAM и вы включаете Memory Tiering, вы можете получить 2 ТБ доступной памяти. Для некоторых сценариев, таких как VDI, возможно соотношение до 1:4 — это позволяет вчетверо увеличить объём памяти при минимальных затратах.

Другие улучшения

В VCF 9.0 было реализовано множество других улучшений функции Memory Tiering. Общие улучшения производительности сделали решение более надёжным, гибким, отказоустойчивым и безопасным. С точки зрения безопасности добавлено шифрование: как на уровне виртуальных машин, так и на уровне хоста. Страницы памяти ВМ теперь могут быть зашифрованы индивидуально для каждой ВМ или сразу для всех машин на хосте — с помощью простой и удобной настройки.

Как начать использовать Advanced Memory Tiering

С чего начать? Как понять, подходят ли ваши рабочие нагрузки для Memory Tiering? Клиентам стоит учитывать следующие факторы при принятии решения о внедрении Memory Tiering:

Активная память

Memory Tiering особенно подходит для клиентов с высоким потреблением (выделено под ВМ более 50%) и низким уровнем активного использования памяти (фактически используемая нагрузками — менее 50% от общего объема DRAM).

Скриншот ниже показывает, как можно отслеживать активную память и объём DRAM с помощью vCenter:

NVMe-устройства

Существуют рекомендации по производительности и ресурсу для поддерживаемых накопителей — в руководстве по совместимости Broadcom (VMware) указано более 1500 одобренных моделей. NVMe-накопители, такие как E3.S, являются модульными и зачастую могут быть установлены в свободные слоты серверов, например, как в Dell PowerEdge, показанном ниже. VMware настоятельно рекомендует клиентам обращаться к руководству по совместимости Broadcom, чтобы обеспечить нужный уровень производительности своих рабочих нагрузок за счёт выбора рекомендованных устройств.

Многоуровневая память Advanced Memory Tiering снижает затраты и одновременно повышает эффективность использования ресурсов, и её будущее выглядит многообещающим. Уже ведётся работа над рядом улучшений, которые обеспечат ещё больший комфорт и дополнительные преимущества. В ближайшие месяцы будет доступно больше информации о технологии Memory Tiering.

Есть вопрос, который администраторы платформы виртуализации VMware vSphere задают регулярно:

Какие идеальные соотношения vCPU к pCPU я должен планировать и поддерживать для максимальной производительности? Как учитывать многопоточность Hyper-Threading и Simultaneous Multithreading в этом соотношении?

Ответ?

Он прост - общего, универсального соотношения не существует — и, более того, сам такой подход может привести к операционным проблемам. Сейчас объясним почему.

Раньше мы пользовались рекомендациями вроде 4 vCPU на 1 pCPU (4:1) или даже 10:1, но этот подход основывался на негласной предпосылке — рабочие нагрузки в основном были в простое. Многие организации начинали свою виртуализацию с консолидации наименее нагруженных систем, и в таких случаях высокое соотношение vCPU:pCPU было вполне обычным явлением.

Так появилась концепция коэффициента консолидации, ставшая основой для планирования ресурсов в виртуальных средах. Даже возникала конкуренция: кто сможет добиться более высокого уровня консолидации. Позже появились технологии вроде Intel Hyper-Threading и AMD SMT (Simultaneous Multithreading), которые позволяли достичь ещё большей консолидации. Тогда расчёт стал сложнее: нужно было учитывать не только физические ядра, но и логические потоки. Огромные Excel-таблицы превратились в операционные панели мониторинга ресурсов.

Но этот подход к планированию и эксплуатации устарел. Высокая динамика изменений в инфраструктуре заказчиков и рост потребления ресурсов со стороны виртуальных машин сделали модель статического соотношения нежизнеспособной. К тому же, с переходом к политике virtual-first, многие компании больше не тестируют приложения на "голом железе" до виртуализации.

А если мы не можем заранее предсказать, что будет виртуализовано, какие ресурсы ему нужны и как долго оно будет работать — мы не можем зафиксировать статическое соотношение ресурсов (процессор, память, сеть, хранилище).

Вместо этого нужно "управлять по конкуренции" (drive by contention)

То есть — инвестировать в пулы ресурсов для владельцев приложений и мониторить эти пулы на предмет высокой загруженности ресурсов и конкуренции (contention). Если возникает конфликт — значит, пул достиг предела, и его нужно расширять. Это требует нового подхода к работе команд, особенно с учётом того, что современные процессоры могут иметь огромное количество ядер.

Именно под такие задачи была спроектирована платформа VMware Cloud Foundation (VCF) и ее инструменты управления — и не только для CPU. На уровне платформы vSphere поддерживает крупные кластеры, автоматически балансируемые такими сервисами, как DRS, которые минимизируют влияние конфликтов на протяжении всего жизненного цикла приложений.

Операционный пакет VCF (Aria) следит за состоянием приложений и пулов ресурсов, сообщает о проблемах с производительностью или нехваткой ёмкости. Такая модель позволяет использовать оборудование эффективно, добиваясь лучшего уровня консолидации без ущерба для KPI приложений. Этого нельзя достичь при помощи фиксированного соотношения vCPU:pCPU.

Поэтому — чтобы не быть в рамках ограничений статических коэффициентов, повысить эффективность использования "железа" и адаптироваться к быстро меняющимся бизнес-реалиям, необходимо переосмыслить операционные модели и инструменты. В них нужно учитывать такие вещи, как:

• Логические CPU не равно физические CPU/ядра (в случае гиперпоточности)
• Важность точного подбора размеров виртуальных машин (right-sizing)

Ключевым фактором снижения рисков становится время вашей реакции на проблемы с производительностью или ёмкостью.

Если обеспечить быструю реакцию пока невозможно — начните с консервативного соотношения 1:1 vCPU:pCPU, не учитывая гиперпоточность. Это безопасный старт. По мере роста зрелости вашей инфраструктуры, процессов и инструментов, соотношение будет естественно улучшаться.

Идеальное финальное соотношение будет уникально для каждой организации, в зависимости от приложений, стека технологий и зрелости эксплуатации.

Вкратце:

Соотношение 1:1 даёт максимальную производительность, но по максимальной цене. Но в мире, где нужно делать больше с меньшими затратами, умение "управлять по конкуренции"— это путь к эффективной работе и инвестициям. VCF и был создан для того, чтобы справляться с этими задачами.

Дункану Эппингу задали вопрос, основанный на материале, который он написал несколько лет назад для углублённого разбора механизма кластеризации VMware vSphere («Clustering Deepdive»).

В этой статье описывается последовательность действий, которые HA выполняет при возникновении отказа. Например, при выходе из строя вторичного (slave/secondary) узла последовательность выглядит так:

• T – сбой вторичного узла.
• T+3 сек – основной узел начинает мониторинг heartbeat-хранилищ в течение следующих 15 секунд.
• T+10 сек – узел помечается как недоступный, и основной узел начинает пинговать управляющую сеть (management network) отказавшего узла. Пинг непрерывно продолжается в течение 5 секунд.
• T+15 сек – если heartbeat-хранилища не настроены, узел объявляется «мёртвым».
• T+18 сек – если heartbeat-хранилища настроены, узел объявляется «мёртвым».

Таким образом, в зависимости от того, есть ли настроенные heartbeat-хранилища, процедура занимает либо 15, либо 18 секунд. Значит ли это, что виртуальные машины сразу же перезапускаются, и если да, то сколько это займёт времени? На самом деле нет, они не перезапускаются моментально, потому что по завершении этой последовательности отказавший вторичный узел только объявляется недоступным. Затем необходимо проверить статус виртуальных машин, которые могли быть затронуты отказом, составить список ВМ для перезапуска и определить их размещение.

Запрос на размещение отправляется либо в DRS, либо обрабатывается самим HA, в зависимости от того, включён ли DRS и доступен ли сервер vCenter. После определения размещения основной (master) узел отправит на хосты команду перезапустить указанные виртуальные машины. После получения списка ВМ хосты начинают их перезапускать партиями по 32 штуки, при этом применяется установленный приоритет и порядок перезапуска. Этот процесс легко может занять 10–15 секунд (и даже больше), что означает, что в идеальных условиях перезапуск ВМ начнётся примерно через 30 секунд после сбоя. Но это лишь момент запуска виртуальной машины — сама ВМ и размещённые на ней сервисы, конечно же, не будут доступны через эти 30 секунд. Процесс включения машины может занять от нескольких секунд до нескольких минут, в зависимости от размера ВМ, гостевой ОС и сервисов, которые должны быть запущены.

Таким образом, хотя для определения и объявления отказа vSphere HA требуется всего 15–18 секунд, на самом деле процесс гораздо более сложный.

В данной статье описывается, как развернуть дома полноценную лабораторию VMware Cloud Foundation (VCF) на одном физическом компьютере. Мы рассмотрим выбор оптимального оборудования, поэтапную установку всех компонентов VCF (включая ESXi, vCenter, NSX, vSAN и SDDC Manager), разберем архитектуру и взаимодействие компонентов, поделимся лучшими практиками...

В январе 2025 года компания VMware опубликовала технический документ под названием «Performance Tuning for Latency-Sensitive Workloads: VMware vSphere 8». Этот документ предоставляет рекомендации по оптимизации производительности для рабочих нагрузок, критичных к задержкам, в среде VMware vSphere 8.

Документ охватывает различные аспекты конфигурации, включая требования к базовой инфраструктуре, настройки хоста, виртуальных машин, сетевые аспекты, а также оптимизацию операционной системы и приложений. В разделе «Host considerations» обсуждаются такие темы, как изменение настроек BIOS на физическом сервере, отключение EVC, управление vMotion и DRS, а также настройка продвинутых параметров, таких как отключение action affinity и открытие кольцевых буферов.

В разделе «VM considerations» рассматриваются рекомендации по оптимальному выделению ресурсов виртуальным машинам, использованию актуальных версий виртуального оборудования, настройке vTopology, отключению функции hot-add, активации параметра чувствительности к задержкам для каждой ВМ, а также использовании сетевого адаптера VMXNET3. Кроме того, обсуждается балансировка потоков передачи и приема данных, привязка потоков передачи к определенным ядрам, ассоциация ВМ с конкретными NUMA-нодами и использование технологий SR-IOV или DirectPath I/O при необходимости.

Раздел о сетевых настройках акцентирует внимание на использовании улучшенного пути передачи данных для NFV-нагрузок и разгрузке сервисов vSphere на DPU (Data Processing Units), также известных как SmartNICs.

Наконец, в разделе, посвященном настройке гостевой ОС и приложений, приводятся рекомендации по оптимизации производительности на уровне операционной системы и приложений, работающих внутри виртуальных машин.

Дункан Эппинг несколько лет назад писал статью о переходе в режим обслуживания с конфигурацией из двух узлов. Поскольку он получил несколько вопросов на эту тему, он решил написать краткую статью, описывающую концепцию обслуживания сайта.

Обратите внимание, что в будущей версии vSAN в интерфейсе появится опция, которая поможет с операциями, описанными ниже.

Прежде всего, вам нужно проверить, реплицированы ли все данные. В некоторых случаях мы видим, что клиенты фиксируют данные (виртуальные машины) в одном месте без репликации, и эти виртуальные машины будут напрямую затронуты, если весь сайт будет переведен в режим обслуживания. Такие виртуальные машины необходимо выключить, либо нужно убедиться, что они перемещены на работающий узел, если требуется их дальнейшая работа. Обратите внимание, что если вы переключаете режимы "Preferred / Secondary", а множество ВМ привязаны к одному сайту, это может привести к значительному объему трафика синхронизации. Если эти виртуальные машины должны продолжать работать, возможно, стоит пересмотреть решение реплицировать их.

Вот шаги, которые Дункан рекомендует предпринять при переводе сайта в режим обслуживания:

1. Убедитесь, что vSAN Witness работает и находится в здоровом состоянии (проверьте соответствующие health checks).
2. Проверьте комплаенс виртуальных машин, которые реплицированы.
3. Настройте DRS (распределённый планировщик ресурсов) в режим "partially automated" или "manual" вместо "fully automated".
4. Вручную выполните vMotion всех виртуальных машин с сайта X на сайт Y.
5. Переведите каждый хост ESXi на сайте X в режим обслуживания с опцией "no data migration".
6. Выключите все хосты ESXi на сайте X.
7. Включите DRS снова в режиме "fully automated", чтобы среда на сайте Y оставалась сбалансированной.
8. Выполните все необходимые работы по обслуживанию.
9. Включите все хосты ESXi на сайте X.
10. Выведите каждый хост из режима обслуживания.

Обратите внимание, что виртуальные машины не будут автоматически возвращаться обратно, пока не завершится синхронизация для каждой конкретной виртуальной машины. DRS и vSAN учитывают состояние репликации! Кроме того, если виртуальные машины активно выполняют операции ввода-вывода во время перевода хостов сайта X в режим обслуживания, состояние данных, хранящихся на хостах сайта X, будет различаться. Эта проблема будет решена в будущем с помощью функции "site maintenance", как упоминалось в начале статьи.

Также для информации об обслуживании сети и ISL-соединения растянутого кластера vSAN прочитайте вот эту статью.

Недавно компания VMware сделала важный анонс относительно компонента балансировщика нагрузки ввода-вывода Storage DRS (SDRS), который включает в себя механизм балансировки нагрузки на основе reservations для SDRS I/O и контроля ввода-вывода Storage I/O Control (SIOC). Все они будут устаревшими в будущих выпусках vSphere. Анонс был сделан в рамках релиза платформы VMware vSphere 8.0 Update 3. Об этом рассказал Дункан Эппинг.

Текущие версии ESXi 8.x и 7.x продолжат поддерживать эту функциональность. Устаревание затронет балансировку нагрузки на основе задержек (latency) для ввода-вывода и балансировку на основе reservations для ввода-вывода между хранилищами в кластере хранилищ Storage DRS. Кроме того, включение SIOC на хранилище и установка reservations и приоритетов с помощью политик хранения SPBM также будут устаревшими. Начальное размещение и балансировка нагрузки Storage DRS на основе хранилищ и настроек политик хранения SPBM для лимитов не будут затронуты.

Для Storage DRS (SDRS) это означает, что функциональность «балансировки по емкости» (capacity balancing) останется доступной, но все, что связано с производительностью, будет недоступно в следующем крупном выпуске платформы. Кроме того, обработка «шумных соседей» (noisy neighbor) через SIOC с использованием приоритетов или, например, reservations ввода-вывода также больше не будет доступна.

Некоторые из вас, возможно, уже заметили, что в интерфейсе на уровне отдельных ВМ исчезла возможность указывать лимит IOPS. Что это значит для лимитов IOPS в целом? Эта функциональность останется доступной через управление на основе политик (SPBM), как и сейчас. Таким образом, если вы задавали лимиты IOPS для каждой ВМ в vSphere 7 отдельно, после обновления до vSphere 8 вам нужно будет использовать настройку через политику SPBM. Опция задания лимитов IOPS через SPBM останется доступной. Несмотря на то, что в интерфейсе она отображается в разделе «SIOC», на самом деле эта настройка применяется через планировщик дисков на уровне каждого хоста.

Современные задачи искусственного интеллекта (AI) и машинного обучения (ML) требуют высокопроизводительных решений при минимизации затрат на инфраструктуру, поскольку оборудование для таких нагрузок стоит дорого. Использование графических процессоров NVIDIA в сочетании с технологией NVIDIA AI Enterprise и платформой VMware Cloud Foundation (VCF) позволяет компаниям...

В обновлении платформы VMware Cloud Foundation 5.2 был представлен новый инструмент командной строки (CLI), называемый VCF Import Tool, который предназначен для преобразования или импорта существующих сред vSphere, которые в настоящее время не управляются менеджером SDDC, в частное облако VMware Cloud Foundation. Вы можете ознакомиться с демонстрацией работы инструмента импорта VCF в этом 6-минутном видео.

Инструмент импорта VCF позволяет клиентам ускорить переход на современное частное облако, предоставляя возможность быстро внедрить Cloud Foundation непосредственно в существующую инфраструктуру vSphere. Нет необходимости приобретать новое оборудование, проходить сложные этапы развертывания или вручную переносить рабочие нагрузки. Вы просто развертываете менеджер SDDC на существующем кластере vSphere и используете инструмент импорта для преобразования его в частное облако Cloud Foundation.

Импорт вашей существующей инфраструктуры vSphere в частное облако VCF происходит без сбоев, поскольку это прозрачно для работающих рабочих нагрузок. В общих чертах, процесс включает сканирование vCenter для обеспечения совместимости с VCF, а затем регистрацию сервера vCenter и его связанного инвентаря в менеджере SDDC. Зарегистрированные экземпляры сервера vCenter становятся доменами рабочих нагрузок VCF, которые можно централизованно управлять и обновлять через менеджер SDDC как часть частного облака VMware. После добавления в инвентарь Cloud Foundation все доступные операции менеджера SDDC становятся доступны для управления преобразованным или импортированным доменом. Это включает в себя расширение доменов путем добавления новых хостов и кластеров, а также применение обновлений программного обеспечения.

Обзор инструмента импорта VCF

Существует два способа начать работу с инструментом импорта VCF.

Если у вас еще нет развернутого виртуального модуля (Virtual Appliance) менеджера SDDC в вашем датацентре, первый шаг — вручную развернуть экземпляр устройства в существующей среде vSphere. Затем вы используете инструмент импорта VCF для преобразования этой среды в управляющий домен VMware Cloud Foundation.

Если в вашем датацентре уже работает экземпляр менеджера SDDC, просто обновите его до версии VCF 5.2 и используйте его для начала импорта существующих сред vSphere как доменов рабочих нагрузок VI. Обратите внимание, что помимо импорта и преобразования сред vSphere в VCF в качестве доменов рабочих нагрузок, инструмент импорта VCF также может быть использован для развертывания NSX в преобразованном или импортированном домене. Это можно сделать как во время преобразования/импорта, так и в качестве операции «Day-2», выполняемой в любое время после добавления среды в качестве домена рабочих нагрузок. Также в инструменте импорта есть функция синхронизации, которая позволяет управлять расхождением конфигураций между сервером vCenter и менеджером SDDC. Подробнее об этих функциях будет рассказано ниже.

Требования для использования инструмента импорта VCF

Чтобы начать работу с инструментом импорта VCF, необходимо выполнить несколько требований. Эти требования различаются в зависимости от того, преобразуете ли вы существующую среду vSphere в управляющий домен VCF или импортируете существующую среду vSphere как домен виртуальной инфраструктуры (VI). Начнем с рассмотрения требований, уникальных для преобразования управляющего домена VCF. Затем перейдем к требованиям, общим для обоих случаев использования — преобразования и импорта.

Примечание: требования и ограничения, указанные в этой статье, основаны на первоначальном релизе инструмента импорта VCF, доступного с VCF 5.2. Обязательно ознакомьтесь с Release Notes, чтобы узнать, применимы ли эти ограничения к версии VCF, которую вы используете.

Требования для преобразования кластера vSphere в управляющий домен VCF

Для преобразования существующей среды vSphere в управляющий домен VCF необходимо учитывать два основных требования.

• Во-первых, среда vSphere, которую вы хотите преобразовать, должна работать на версии vSphere 8.0 Update 3 или выше. Это относится как к экземпляру сервера vCenter, так и к хостам ESXi. Эта версия vSphere соответствует спецификации (Bill of Materials, BOM) VCF 5.2. Это требование связано, в частности, с тем, что сначала нужно развернуть виртуальный модуль менеджера SDDC в кластере, а версия 5.2 этого устройства требует версий vCenter и ESXi 8.0 Update 3 (или выше).
• Во-вторых, при преобразовании среды vSphere сервер vCenter должен работать в кластере, который будет преобразован. В документации это называется требованием «совместного размещения» сервера vCenter с кластером.

Требования для импорта кластера vSphere в домен VI VCF

Как и при преобразовании в новый управляющий домен, при импорте среды vSphere в домен VI VCF также необходимо учитывать два основных требования.

• Во-первых, поддерживаемые версии vSphere для импорта в качестве домена VI — это vSphere 7.0 Update 3 и выше. Это включает как экземпляр сервера vCenter, так и хосты ESXi. Минимальная версия 7.0 с обновлением 3 соответствует версии vCenter и ESXi, которая входит в спецификацию VCF 4.5 (BOM).
• Во-вторых, при импорте среды vSphere сервер vCenter должен работать либо в кластере, который преобразуется (совместно размещенный), либо в кластере в управляющем домене.

Общие требования при преобразовании и импорте кластеров vSphere

Помимо указанных выше требований, существуют следующие общие требования для преобразования и импорта инфраструктуры vSphere.

• Все хосты внутри кластера vSphere должны быть однородными. Это означает, что все хосты в кластере должны быть одинаковыми по мощности, типу хранилища и конфигурации (pNIC, VDS и т.д.). Конфигурации серверов могут различаться между кластерами, но внутри одного кластера хосты должны быть одинаковыми.
• Кластеры, которые будут преобразованы или импортированы, должны использовать один из трех поддерживаемых типов хранилищ: vSAN, NFS или VMFS на Fibre Channel (FC). Это часто вызывает путаницу, так как при развертывании с нуля (greenfield deployment) с использованием устройства Cloud Builder для управляющего домена требуется всегда использовать vSAN. Учтите, что требование vSAN не применяется к преобразованным управляющим доменам, где можно использовать vSAN, NFS или VMFS на FC.
• При использовании vSAN минимальное количество хостов для управляющего домена всегда составляет четыре. Однако при использовании NFS или VMFS на FC минимальное количество хостов составляет три. Это также отличается от требований при развертывании с нуля с использованием Cloud Builder.
• Режим расширенной связи (Enhanced Linked Mode, ELM) не поддерживается инструментом импорта VCF. Каждый экземпляр сервера vCenter, который будет преобразован или импортирован в качестве домена рабочих нагрузок VCF, должен находиться в собственной доменной структуре SSO. Таким образом, каждый преобразованный или импортированный экземпляр vCenter создаст изолированный домен рабочих нагрузок в VCF. Это может стать проблемой для клиентов, которые привыкли к централизованному управлению своей средой VCF через одну панель управления. Обратите внимание на новые дэшборды мониторинга VCF Operations (ранее Aria Operations), которые могут помочь смягчить это изменение.
• Все кластеры в инвентаре vCenter должны быть настроены с использованием одного или нескольких выделенных vSphere Distributed Switches (VDS). Учтите, что стандартные коммутаторы vSphere (VSS) не поддерживаются. Более того, если в кластере настроен VSS, его необходимо удалить перед импортом кластера. Также важно отметить, что VDS не могут быть общими для нескольких кластеров vSphere.
• В инвентаре vCenter не должно быть отдельных хостов ESXi. Отдельные хосты нужно либо переместить в кластер vSphere, либо удалить из инвентаря vCenter.
• Во всех кластерах должно быть включено полное автоматическое распределение ресурсов (DRS Fully Automated), и на всех хостах должна быть настроена выделенная сеть для vMotion.
• Все адаптеры vmkernel должны иметь статически назначенные IP-адреса. В рамках процесса преобразования/импорта в менеджере SDDC будет создан пул сетей с использованием этих IP-адресов. После завершения импорта эти IP-адреса не должны изменяться, поэтому они должны быть статически назначены.
• Среды vSphere не могут иметь несколько адаптеров vmkernel, настроенных для одного и того же типа трафика.

Значимые ограничения инструмента импорта в VCF 5.2

После указания требований для использования инструмента импорта VCF важно отметить несколько ограничений, связанных с версией VCF 5.2, о которых нужно знать. Имейте в виду, что рабочие процессы импорта VCF включают функцию «проверки», которая сканирует инвентарь vCenter перед попыткой преобразования или импорта. Если обнаруживаются ограничения, процесс будет остановлен.

Следующие топологии не могут быть преобразованы или импортированы с использованием инструмента импорта VCF в версии 5.2:

• Среда vSphere, настроенная с использованием NSX.
• Среды vSphere, настроенные с балансировщиком нагрузки AVI.
• Среды vSphere, настроенные с растянутыми кластерами vSAN Stretched Clusters.
• Среды vSphere, где vSAN настроен только в режиме сжатия (compression-only mode).
• Кластеры vSphere с общими распределенными коммутаторами vSphere (VDS).
• Среды vSphere с включенной контрольной панелью IaaS (ранее vSphere with Tanzu).
• Среды vSphere, настроенные с использованием протокола управления агрегированием каналов (LACP).
• Среды VxRail.

Установка NSX на преобразованные и импортированные домены рабочих нагрузок

При обсуждении ограничений, связанных с инструментом импорта VCF, мы отметили, что нельзя преобразовывать или импортировать кластеры, настроенные для NSX. Однако после того, как домен будет преобразован/импортирован, вы можете использовать инструмент импорта VCF для установки NSX. Вы можете выбрать установку NSX одновременно с преобразованием/импортом или в любое время после этого в рамках операций Day-2.

Одна важная вещь, которую следует помнить при использовании инструмента импорта VCF для установки NSX на преобразованный или импортированный домен рабочих нагрузок, заключается в том, что виртуальные сети и логическая маршрутизация не настраиваются в процессе установки NSX. Инструмент импорта устанавливает NSX и настраивает распределенные группы портов в NSX Manager. Это позволяет начать использовать распределенный межсетевой экран NSX для защиты развернутых рабочих нагрузок. Однако для того, чтобы воспользоваться возможностями виртуальных сетей и логического переключения, предоставляемыми NSX, требуется дополнительная настройка, так как вам нужно вручную настроить туннельные эндпоинты хоста (TEPs).

Использование инструмента импорта VCF для синхронизации изменений с сервером vCenter

Помимо возможности импортировать существующую инфраструктуру vSphere в Cloud Foundation, инструмент импорта также предоставляет функцию синхронизации, которая позволяет обновлять менеджер SDDC с учетом изменений, внесенных в инвентарь сервера vCenter, что помогает поддерживать согласованность и точность всей среды.

При управлении инфраструктурой vSphere, которая является частью частного облака Cloud Foundation, могут возникнуть ситуации, когда вам потребуется внести изменения непосредственно в среду vSphere. В некоторых случаях изменения, сделанные непосредственно в инвентаре vCenter, могут не быть захвачены менеджером SDDC. Если инвентарь менеджера SDDC выйдет из синхронизации с инвентарем vCenter, это может временно заблокировать некоторые рабочие процессы автоматизации. Чтобы избежать этого, вы запускаете инструмент импорта CLI с параметром «sync», чтобы обновить инвентарь менеджера SDDC с учетом изменений, внесенных в конфигурацию vCenter.

В VMware Cloud Foundation (VCF) версии 5.2 появилась новая консоль, которая добавляет диагностические возможности в Operations VMware Cloud Foundation (VMware Aria Operations). VMware Cloud Foundation Operations включен в VCF и VMware vSphere Foundation.

Новые функции включают "Общие выводы" и "Рекомендации по безопасности". Кроме того, такие разделы, как "Серверы vCenter", "Хосты ESXi", "Развертывание рабочих нагрузок" и "Кластеры vSAN", которые ранее были доступны в VMware Cloud Foundation Operations, теперь включены для улучшенной видимости. Также улучшена интеграция с VMware Aria Operations for Logs, что предоставляет больше информации о миграциях vMotion и снапшотах. Чтобы включить эту функцию, необходимо подключить Operations к Operations for Logs и хотя бы одному vCenter. При добавлении дополнительных компонентов VMware vSphere Foundation и VCF станут доступны дополнительные наборы данных. Давайте рассмотрим каждый раздел более подробно.

Общие выводы

В новой версии VMware Cloud Foundation Operations объединены диагностические возможности (из Skyline Health Diagnostics, Skyline Advisor и VMware Aria Operations for Logs) в единый интерфейс, представленный в новой консоли. С помощью Skyline можно применять рекомендации по безопасности и эксплуатации на основе версий. Теперь VMware Cloud Foundation Operations и VMware Aria Operations for Logs привязаны к одним и тем же конечным эндпоинтам, что способствует появлению новых диагностических выводов в консоли, уменьшая необходимость в развертывании дополнительного программного обеспечения (сокращает необходимость в Skyline Advisor Collector и виртуальной машине Skyline Health Diagnostics). Эта бесшовная интеграция уменьшает дублирование усилий, о которых упоминалось ранее, и упрощает развертывание и управление средой. В результате получается системный подход к представлению диагностических выводов клиентам.

Вот некоторые распространенные задачи:

• Просмотр всех файндингов
• Определение общего количества ресурсов
• Категоризация выводов по критичности (критические, срочные и предупреждения)
• Классификация по типу:
  • Рекомендации по безопасности
  • Доступность
  • Проверки перед обновлением
  • Диагностика эксплуатации
  • Производительность
• Уточнение их представления с помощью фильтров на основе:
  • Инвентарь VCF
  • Компоненты VCF
  • Тип файндинга
  • Серьезность
  • Возможности:
    • vMotions
    • Снапшоты
    • Развертывание рабочих нагрузок
    • Домены рабочих нагрузок
      • DRS
      • HA

Для доступа к диагностической консоли выберите "Diagnostics" в левой панели навигации. На странице Home -> Overview найдите ссылки на "Appliances Health & Management".

Рисунок 1. Дэшборд главной страницы.

Рисунок 2. Дэшборд диагностики из меню слева.

В основном дэшборде «Overall Findings» вы можете быстро просмотреть все файндинги. Вы можете уточнить их количество, выбрав компоненты в левой панели. Кроме того, вы можете искать конкретные файндинги или использовать подстановочные знаки в строке поиска, расположенной выше списка файндингов.

Рисунок 3. Опции фильтрации и поиска на панели «Diagnostic Findings».

Вы можете углубиться в просмотр конкретных деталей, выбрав отдельный файндинг, например, Last Observed, Affected Objects и Recommendations.

Рисунок 4. Просмотр Last Objerved и Affected Objects.

На вкладке «Affected Objects» вы можете найти имя объекта, время его первого наблюдения (Occurrence Time) и время последней проверки (Check Time). Окружение будет сканироваться каждые четыре часа, и детали на этой вкладке будут обновляться соответственно. Не забудьте учитывать следующую информацию:

Рисунок 5. Просмотр деталей «Affected Objects».

В разделе «Recommendations» вы можете найти версию продукта, в которой проблема была решена, а также статью базы знаний (KB), в которой представлены детали о проблеме, исправлении и воркэраунде.

Рисунок 6. Просмотр рекомендаций по исправленным версиям и статьям базы знаний (KB).

Вот некоторые распространенные сценарии использования:

• Просмотр VMSA и CVE для определения возможных проблем и обновлений для определенного набора серверов.
• Помощь в планировании обновлений vCenter и ESXi для решения нескольких файндингов одновременно.
• Разделение списка файндингов по регионам, чтобы распределить работу среди сотрудников, работающих в разных регионах.

Управление сертификатами

Все сертификаты в среде будут отображены здесь. Эти сертификаты существуют во всех приложениях VMware для обеспечения идентификации приложений (с целью уменьшения риска атак типа «man in the middle»). Поскольку каждое приложение может иметь до трех сертификатов, управление сертификатами занимает много времени и является сложным процессом. С учетом даты истечения срока действия и внешнего центра сертификации, управление графиком обновления и импорта сертификатов может вызывать проблемы.

Когда вы настраиваете консоль диагностики, то заполняется и панель управления сертификатами. Вы можете легко увидеть все сертификаты для конкретного сервера, включая информацию о том, являются ли они самоподписанными или сертификатами CA, а также активны ли они. Для активных сертификатов пользователи могут увидеть оставшееся время до истечения срока действия, что помогает начать процесс обновления сертификатов до их истечения, чтобы предотвратить возможные перебои в работе.

Рисунок 7. Обзор дэшборда управления сертификатами.

Вот некоторые распространенные сценарии использования:

• Проверка наличия «неактивных» сертификатов и их немедленное исправление.
• Просмотр даты истечения срока действия и немедленное исправление самоподписанных сертификатов.
• Превентивное предотвращение истечения срока действия сертификатов.

vCenter

В дэшборде диагностики vCenter вы можете легко просмотреть все vCenter, подключенные к VCF Operations. Здесь объединяются все данные из vCenter, а также данные из VCF Operations. Вы можете быстро проверить операционный статус каждого vCenter. Если какой-либо vCenter не работает, вы можете определить количество затронутых хостов ESXi и виртуальных машин. Кроме того, вы можете увидеть все службы, запущенные на конкретном vCenter. В течение нескольких секунд можно определить, какие службы не работают, устранить проблемы и вернуть их в рабочее состояние. Этот процесс занял бы 30 минут или больше, если бы использовались традиционные методы, такие как проверка vCenter через консоль сервера и файлы журналов. При необходимости можно выбрать отдельные vCenter для более детального исследования.

Рисунок 8. Дэшборд vCenter.

Вот некоторые распространенные сценарии использования:

• Проверка доступности любого vCenter и определение затронутых серверов и виртуальных машин.
• Просмотр служб на каждом vCenter, чтобы убедиться, что все они работают нормально.

Хосты ESXi

Дэшборд ESXi предоставляет важную диагностическую информацию о хостах ESXi. Во-первых, вы можете проверить наличие «неотвечающих ESXi» серверов, так как это вопросы высокого приоритета. Далее, вы можете проверить, находятся ли какие-либо ESXi серверы в режиме обслуживания и определить, должны ли они оставаться в этом режиме или выйти из него. Также важно обратить внимание на серверы ESXi, которые были «отключены» или «не отвечают» в течение длительного времени. При выборе каждого ESXi сервера вы можете получить доступ к настройкам «родительского кластера», что может предоставить ценные сведения о возможных проблемах. В течение нескольких секунд можно выявить проблемы и инициировать необходимые действия по их устранению.

Рисунок 9. Дэшборд ESXi.

Вот некоторые распространенные сценарии использования:

• Выявление всех «не отвечающих» серверов ESXi и их восстановление до нормального состояния.
• Проверка ESXi режиме обслуживания для уверенности в том, что они действительно должны там находиться. Вывод из режима обслуживания как можно скорее для оптимального использования ресурсов.
• Определение «Родительского кластера» конкретного ESXi и проверка правильности всех настроек.

Развертывание рабочих нагрузок

На панели управления развертыванием рабочих нагрузок вы можете просмотреть общие задачи по управлению нагрузкой, такие как «Создать новую виртуальную машину», «Развернуть OVF» и «Клонировать виртуальную машину». Вы можете быстро выявить любые сбои. При просмотре деталей пользователи могут увидеть информацию, такую как «Время запроса», «Имя виртуальной машины», «Инициатор», «vCenter» и «Кластер». С этой информацией вы можете исследовать окружение на наличие потенциальных проблем, выполнить необходимые исправления и уведомить инициаторов о необходимости повторного выполнения их задач.

Рисунок 10. Дэшборд развертывания рабочих нагрузок.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с развертыванием рабочих нагрузок.
• Проверка любых сбоев для выявления основной причины проблемы.
• Просмотр «инициаторов», чтобы убедиться, что все пользователи правильно назначены.

Миграции vMotion

Технология vMotion существует уже достаточно давно. Вы можете наблюдать за активностью vMotion в списке «recent tasks» в консоли vCenter. Однако ранее не было возможности видеть все события vMotion из одного представления. Теперь у вас есть такая возможность. Вы можете выбрать каждый vCenter, чтобы просмотреть все случаи vMotion, определяя как сбои, так и успешные события. В случае сбоя вы можете просмотреть такие детали, как имя виртуальной машины, источник, назначение и время, что поможет выявить и устранить проблему, предотвращая аналогичные сбои в будущем. Для тех, кто использует HCX (который использует vMotion), также фиксируются все активности HCX vMotion.

Рисунок 11. Дэшборд vMotion.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных с vMotion.
• Просмотр всех локаций, а также каждого vCenter на основе прошлых проблем.
• Проверка исходного и целевого хостов для выявления проблем.

Снапшоты

В диагностической консоли вы можете просмотреть все снапшоты в окружении. Вы сможете определить наиболее проблемные виртуальные машины с проблемами снапшотов, особенно те, которые требуют консолидации. Еще один важный аспект — оценка общего количества снимков для семи наиболее важных виртуальных машин. У вас есть возможность фильтровать успешные и неудачные снимки. Для каждой проблемы, связанной со снимками, вы можете просмотреть такие детали, как виртуальные машины, vCenter, хранилище данных и временная метка. Это должно предоставить достаточно информации, чтобы определить, является ли проблема специфичной для конкретной виртуальной машины или это системная проблема, связанная с vCenter, ESXi или хранилищем данных.

Рисунок 12. Дэшборд снапшотов.

Вот некоторые распространенные сценарии использования:

• Определение всех диагностических файндингов, связанных со снапшотами.
• Просмотр любых сбоев.
• Сопоставление любого сбоя с проблемой ESXi, графиком резервного копирования или другими сбоями (сеть, хранилище и т.д.).

Кластеры vSAN

Раздел «vSAN Health» в диагностической консоли предоставляет обзор состояния инфраструктуры vSAN. Вы можете быстро отфильтровать количество предупреждений «Красного», «Оранжевого» и «Желтого» уровня. При выборе каждого кластера появятся детали о свойствах выбранного кластера, которые помогут убедиться, что все необходимые настройки корректны. Ниже вы можете просмотреть детали каждого предупреждения, что поможет правильно расставить приоритеты и устранить проблемы для обеспечения наилучшей производительности и стабильности кластера vSAN.

Рисунок 13. Панель управления здоровьем vSAN.

Вот некоторые распространенные сценарии использования:

• Просмотр всех предупреждений «Красного», «Оранжевого» и «Желтого» уровня.
• Проверка всех свойств выбранного кластера на правильность настроек.
• Прохождение по всем выводам по отдельности для планирования обновления с целью решения проблем.

После изучения всех функций в диагностической консоли (файндинги, сертификаты, vCenter, ESXi, развертывание рабочих нагрузок, vMotion, снапшоты и кластеры vSAN) вы можете оценить значимость новых дэшбордов. Некоторые из них представляют собой недавно добавленные функции из других продуктов, а другие — это детали существующих панелей, объединенные в этой консоли. Цель заключается в предоставлении ценных сведений с минимальными усилиями по развертыванию и настройке. Это позволит использовать существующие экземпляры Aria Operations и Operations for Logs, что в конечном итоге сэкономит время клиентов на решение проблем и сократит время простоя и обслуживания.

VMware vSphere давно зарекомендовала себя как одна из ведущих платформ для виртуализации, обеспечивая мощные инструменты для управления виртуальными машинами (VM) и инфраструктурой центров обработки данных (ЦОД). В версии VMware vSphere 8 Update 3 была введена новая важная функция — Live Patch. Это нововведение позволяет администраторам вносить критические исправления и обновления безопасности в ядро гипервизора ESXi без необходимости перезагрузки системы или отключения виртуальных машин. В данной статье мы рассмотрим, что такое Live Patching, его преимущества, технические аспекты работы и потенциальные ограничения.

Выход платформы VMware vSphere 8 переопределил подход к управлению жизненным циклом и обслуживанием инфраструктуры vSphere. Решение vSphere Lifecycle Manager упрощает управление образами кластеров, обеспечивает полный цикл управления драйверами и прошивками, а также ускоряет полное восстановление кластера. Управление сертификатами происходит без сбоев, а обновления vCenter можно выполнять с гораздо меньшими простоями по сравнению с прошлыми релизами платформы.

vSphere 8 Update 3 продолжает эту тенденцию снижения и устранения простоев с введением функции vSphere Live Patch.

vSphere Live Patch позволяет обновлять кластеры vSphere и накатывать патчи без миграции рабочих нагрузок с целевых хостов и без необходимости перевода хостов в полный режим обслуживания. Патч применяется в реальном времени, пока рабочие нагрузки продолжают выполняться.

Требования данной техники:

• vSphere Live Patch является опциональной функцией, которую необходимо активировать перед выполнением задач восстановления.
• vCenter должен быть версии 8.0 Update 3 или выше.
• Хосты ESXi должны быть версии 8.0 Update 3 или выше.
• Настройка Enforce Live Patch должна быть включена в глобальных настройках восстановления vSphere Lifecycle Manager или в настройках восстановления кластера.
• DRS должен быть включен на кластере vSphere и работать в полностью автоматическом режиме.
• Для виртуальных машин с включенной vGPU необходимо активировать Passthrough VM DRS Automation.
• Текущая сборка кластера vSphere должна быть пригодна для применения live-патчинга (подробности ниже).

Как работает Live Patching

Кликните на картинку, чтобы открыть анимацию:

Распишем этот процесс по шагам:

• Хост ESXi переходит в режим частичного обслуживания (partial maintenance mode). Частичный режим обслуживания — это автоматическое состояние, в которое переходит каждый хост. В этом особом состоянии существующие виртуальные машины продолжают работать, но создание новых ВМ на хосте или миграция ВМ на этот хост или с него запрещены.
• Новая версия компонентов целевого патча монтируется параллельно с текущей версией.
• Файлы и процессы обновляются за счет смонтированной версии патча.
• Виртуальные машины проходят быструю паузу и запуск (fast-suspend-resume) для использования обновленной версии компонентов.

Не все патчи одинаковы

Механизм vSphere Live Patch изначально доступен только для определенного типа патчей. Патчи для компонента выполнения виртуальных машин ESXi (virtual machine execution component) являются первыми целями для vSphere Live Patch.

Патчи, которые могут изменить другие области ESXi, например патчи VMkernel, изначально не поддерживаются для vSphere Live Patch и пока требуют следования существующему процессу патчинга, который подразумевает перевод хостов в режим обслуживания и эвакуацию ВМ.

Обновления vSphere Live Patches могут быть установлены только на поддерживаемые совместимые версии ESXi. Каждый Live Patch будет указывать, с какой предыдущей сборкой он совместим. vSphere Lifecycle Manager укажет подходящие версии при определении образа кластера. Также вы можете увидеть подходящую версию в репозитории образов vSphere Lifecycle Manager:

Например, patch 8.0 U3a 23658840 может быть применен только к совместимой версии 8.0 U3 23653650. Системы, которые не работают на совместимой версии, все равно могут быть обновлены, но для этого будет использован существующий процесс "холодных" патчей, требующий перевода хостов в режим обслуживания и эвакуации ВМ.

Соответствие образа кластера будет указывать на возможность использования Live Patch.

Быстрое приостановление и возобновление (fast-suspend-resume)

Как упоминалось ранее, патчи для компонента выполнения виртуальных машин в ESXi являются первой целью для vSphere Live Patch. Это означает, что хотя виртуальные машины не нужно эвакуировать с хоста, им нужно выполнить так называемое быстрое приостановление и возобновление (FSR) для использования обновленной среды выполнения виртуальных машин.

FSR виртуальной машины — это ненарушающее работу действие, которое уже используется в операциях с виртуальными машинами при добавлении или удалении виртуальных аппаратных устройств (Hot Add) в работающие виртуальные машины.

Некоторые виртуальные машины несовместимы с FSR. Виртуальные машины, настроенные с включенной функцией Fault Tolerance, машины, использующие Direct Path I/O, и vSphere Pods не могут использовать FSR и нуждаются в участии администратора. Это может быть выполнено либо путем миграции виртуальной машины, либо путем перезагрузки виртуальной машины.

Сканирование на соответствие в vSphere Lifecycle Manager укажет виртуальные машины, несовместимые с FSR, и причину несовместимости:

После успешного восстановления кластера любые хосты, на которых работают виртуальные машины, не поддерживающие FSR, будут продолжать сообщать о несоответствии требованиям. Виртуальные машины необходимо вручную переместить с помощью vMotion или перезагрузить. Только тогда кластер будет полностью соответствовать требованиям (compliant).

Отметим, что vSphere Live Patch несовместим с системами, работающими с устройствами TPM или DPU, использующими vSphere Distributed Services Engine.

Недавно мы писали о новых возможностях пакета обновлений платформы виртуализации VMware vSphere 8 Update 3. Сегодня мы более детально рассмотрим, что нового там появилось в плане поддержки карт GPU.

Новые функции охватывают несколько областей, начиная с использования vGPU-профилей разных типов и размеров вместе и заканчивая внесением изменений в расширенные параметры DRS, которые определяют, как ВМ с поддержкой vGPU будет обрабатываться со стороны vMotion, например. Все эти улучшения направлены на упрощение жизни системных администраторов, дата-сайентистов и других пользователей, чтобы они могли использовать свои рабочие нагрузки на платформах vSphere и VCF.

Гетерогенные типы vGPU-профилей с разными размерами

В VMware vSphere мы можем назначить машине vGPU-профиль из набора заранее определенных профилей, чтобы предоставить ей определенную функциональность. Набор доступных vGPU-профилей появляется после установки NVIDIA vGPU менеджера/драйвера на уровне хоста в ESXi посредством vSphere Installation Bundle (VIB).

Эти vGPU-профили называются профилями типа C в случае, если профиль предназначен для интенсивной вычислительной работы, такой как обучение моделей машинного обучения. Существуют и несколько других типов vGPU-профилей, среди которых Q (Quadro) для графических рабочих нагрузок являются одними из самых популярных. Буквы «c» и «q» стоят в конце названия vGPU-профиля, отсюда и название этого типа.

В предыдущем обновлении vSphere 8 Update 2 мы могли назначать машине vGPU-профили, которые предоставляли поддержку различных видов функциональности, используя при этом одно и то же устройство GPU. Ограничением в этой версии vSphere было то, что они должны были быть vGPU-профилями одного и того же размера, например, те, которые заканчиваются на 8q и 8c. Здесь «8» представляет количество гигабайт памяти на самом GPU (иногда называемой framebuffer-памятью), которая назначена ВМ, использующей этот vGPU-профиль. Это значение может изменяться в зависимости от модели основного GPU.

При использовании GPU A40 или L40s мы можем иметь vGPU-профиль типа C, предназначенный для вычислительно интенсивной работы, такой как машинное обучение, и vGPU-профиль типа Q (предназначенный для графической работы), назначенные разным ВМ, которые делят один и тот же физический GPU на хосте.

Теперь в vSphere 8 Update 3 можно продолжать смешивать эти разные типы vGPU-профилей на одном физическом GPU, а также иметь vGPU-профили разного размера памяти, которые делят один и тот же GPU.

В качестве примера новой функциональности vSphere 8 Update 3: ВМ1 с vGPU-профилем l40-16c (для вычислительных нагрузок) и ВМ2 с vGPU-профилем l40-12q (для графических нагрузок) делят одно и то же устройство L40 GPU внутри хоста. Фактически, все вышеупомянутые виртуальные машины делят одно и то же физическое устройство L40 GPU.

Это позволяет лучше консолидировать рабочие нагрузки на меньшее количество GPU, когда рабочие нагрузки не потребляют весь GPU целиком. Возможность размещения гетерогенных типов и размеров vGPU-профилей на одном устройстве GPU применяется к GPU L40, L40s и A40 в частности, так как эти GPU имеют двойное назначение. То есть они могут обрабатывать как графические, так и вычислительно интенсивные задачи, в то время как GPU H100 предназначен исключительно для вычислительно интенсивных задач.

Включение настроек кластера для DRS и мобильности ВМ с vGPU

В vSphere Client версии 8.0 U3 появились новые настройки кластера, которые предоставляют более удобный метод настройки расширенных параметров для кластера DRS. Вы можете установить ограничение по времени приостановки ВМ, которое будет допускаться для машин с vGPU-профилями, которым может потребоваться больше времени, чем по умолчанию, для выполнения vMotion. Время приостановки по умолчанию для vMotion составляет 100 секунд, но этого может быть недостаточно для некоторых ВМ с большими vGPU-профилями. Дополнительное время требуется для копирования памяти GPU на целевой хост. Вы также можете узнать оценочное время приостановки для вашей конкретной ВМ с поддержкой vGPU в vSphere Client. Для получения дополнительной информации о времени приостановки, пожалуйста, ознакомьтесь с этой статьей.

В vSphere 8 Update 3 появился более удобный пользовательский интерфейс для настройки расширенных параметров для кластера DRS, связанных с vMotion виртуальных машин.

Прежде чем мы рассмотрим второй выделенный элемент на экране редактирования настроек кластера ниже, важно понять, что vGPU как механизм доступа к GPU является одной из множества техник, которые находятся в "спектре проброса устройств" (Passthrough spectrum). То есть, vGPU на самом деле является одной из форм прямого доступа. Возможно, вы считали, что подходы прямого проброса и vGPU сильно отличаются друг от друга до настоящего времени, так как они действительно разделены в vSphere Client при выборе добавления нового PCIe-устройства к ВМ. Однако, они тесно связаны друг с другом. Фактически, vGPU ранее назывался "опосредованным пробросом" (mediated passthrough). Этот спектр использования прямого доступа различными способами показан здесь.

Именно поэтому в vSphere Client на выделенном участке экрана ниже используются термины «Passthrough VM» и «Passthrough Devices». Эти термины на самом деле относятся к виртуальным машинам с поддержкой vGPU – и таким образом, обсуждение касается включения DRS и vMotion для виртуальных машин с поддержкой vGPU на этом экране. vMotion не разрешен для виртуальных машин, использующих фиксированный прямой доступ, как показано на левой стороне диаграммы выше.

Новая функция интерфейса позволяет пользователю включить расширенную настройку vSphere под названием «PassthroughDrsAutomation». С включенной этой настройкой, при соблюдении правил по времени приостановки, виртуальные машины в этом кластере могут быть перемещены vMotion на другой хост по решению DRS. Для получения дополнительной информации об этих расширенных настройках DRS, пожалуйста, ознакомьтесь с этой статьей.

Доступ к медиа-движку GPU

Единый медиа-движок на GPU может использоваться виртуальной машиной, которая хостит приложение, которому требуется выполнять транскодирование (кодирование/декодирование) на GPU, а не на более медленном CPU, например, для видео-приложений.

В vSphere 8 Update 3 поддерживается новый vGPU-профиль для виртуальных машин, которым требуется доступ к медиа-движку внутри GPU. Только одна виртуальная машина может использовать этот медиа-движок. Примеры таких vGPU-профилей («me» означает media engine):

• a100-1-5cme (один срез)
• h100-1-10cme (два среза)

Более высокая скорость vMotion виртуальных машин с большими vGPU-профилями

Новые улучшения в vMotion позволяют нам увеличивать пропускную способность для сети vMotion со скоростью 100 Гбит/с до 60 Гбит/с для vMotion виртуальной машины, к которой подключен современный GPU (H100, L40S), что сокращает время vMotion. Это не относится к GPU A100 и A30, которые относятся к более старой архитектуре (GA100).

Новые технические документы и рекомендации по проектированию GPU с VMware Private AI Foundation with NVIDIA

Недавно были выпущены два важных публикации авторами VMware. Агустин Маланко Лейва и команда опубликовали решение VMware Validation Solution для инфраструктуры Private AI Ready Infrastructure, доступное здесь.

Этот документ предоставляет подробное руководство по настройке GPU/vGPU на VMware Cloud Foundation и многим другим факторам для организации вашей инфраструктуры для развертывания VMware Private AI.

Одним из ключевых приложений, которое будут развертывать в первую очередь в инфраструктуре VMware Private AI Foundation с NVIDIA, является генерация с дополненным извлечением или RAG. Фрэнк Деннеман и Крис МакКейн подробно рассматривают требования к безопасности и конфиденциальности и детали реализации этого в новом техническом документе под названием VMware Private AI – Privacy and Security Best Practices.

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.

Руководство предлагает пошаговые инструкции для ручного восстановления вашего экземпляра VMware Cloud Foundation, а также комплексную автоматизацию в виде модуля PowerShell, чтобы ускорить и упростить процесс ручного восстановления, используя данные из инвентаря VCF SDDC Manager для реконструкции конфигураций. Это устраняет необходимость обращаться к документации, которая может быстро устареть в условиях постоянно меняющегося и сложного программно-определяемого центра обработки данных.

Сценарии использования

Примеры сценариев, когда вам может понадобиться этот процесс:

• Полный сбой площадки
• Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
• Катастрофическая логическая порча данных

Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).

Немного о DORA

DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.

DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.

Организации также должны разработать планы обеспечения непрерывности бизнеса и восстановления после аварий для различных сценариев киберрисков, таких как сбои ИКТ-услуг, природные катастрофы и кибератаки. Эти планы должны включать меры по резервному копированию и восстановлению данных, а также процессы восстановления систем.

Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.

Восстановление экземпляра VCF — это не просто на бумаге

Регламенты возлагают на предприятия, такие как финансовые учреждения и связанные с ними поставщики технологий третьих сторон, серьезные обязательства по разработке надежных планов реагирования на сбои их систем.

Организации должны будут проводить периодическое тестирование своих планов, инструментов и систем, чтобы продемонстрировать способность восстанавливать критически важную инфраструктуру в случае сбоев в своевременной и повторяемой манере.

Краткое описание решения

Решение VMware Cloud Foundation Instance Recovery использует комбинацию процессов восстановления из бэкапов, восстановления работоспособности и ребилда данных для воссоздания экземпляра VCF с точно такой же конфигурацией, даже если было утрачено основное оборудование и центр обработки данных, в котором он находился.

• Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
• Выполнение частичного развертывания VCF
• Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
• Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
• Восстановление NSX Edges
• Восстановление рабочих нагрузок (виртуальных машин)
• Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)

Временная шкала восстановления VMware Cloud Foundation Instance Recovery

Чтобы минимизировать время общего восстановления в VMware Cloud Foundation, задачи восстановления могут выполняться в нескольких доменах рабочих нагрузок по перекрывающемуся графику, адаптированному под требования клиентов. Временная шкала предназначена для следующего примера конфигурации:

• 3 домена рабочих нагрузок VI
• Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
• Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
• Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.

Автоматизация с помощью PowerShell

Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.

Это особенно полезно в случаях, когда задачи выполняются многократно, например, для каждого хоста ESXi или для каждой восстанавливаемой виртуальной машины.

Процесс полагается на способность извлекать данные из резервной копии менеджера SDDC, которую вы собираетесь восстановить. Это означает, что автоматизация может восстановить последнюю жизнеспособную резервную копию без необходимости полагаться на актуальность ручных процессов и документации.

Пример извлечения данных конфигурации из резервной копии менеджера SDDC для использования при восстановлении:

После извлечения каждый шаг процесса использует эти данные для контроля и автоматизации реконструкции.

В лабораторных условиях полные экземпляры VCF, включая домен управления и домены рабочих нагрузок VI, были восстановлены всего за два часа. Многие задачи для дополнительных доменов рабочих нагрузок можно выполнять параллельно или в пересекающемся режиме, чтобы минимизировать общее время восстановления экземпляра.

Это уже было протестировано в лабораторной среде одним из крупнейших клиентов VCF, и они очень рады тому, что это решение предлагает им в плане соблюдения нормативных требований.

У Broadcom есть планы по дальнейшему расширению автоматизации и процессов для поддержки дополнительных топологий, конфигураций и технологий, так что следите за обновлениями!

На сайте проекта Sample Exchange появилась утилита vKaan - vSphere Health Check - решение для управления виртуальной средой, предназначенное для поддержания конфигураций инсталляций VMware vSphere. Пакет vKaan позволяет отслеживать конфигурации Cluster HA и DRS и идентифицировать различающиеся объекты. Он также выявляет нарушения правил vSphere DRS и генерирует оповещения. Идентифицируя нарушения правил, он помогает обеспечить стабильность, эффективность и соответствие вашей среды vSphere желаемому состоянию.

Требования к системе Aria Operations

• Для интеграции с пакетом управления версия vSphere API должна быть выше 8.0.1.0 (версии vSphere 7.x не поддерживаются).
• Версия Aria Operations Manager должна быть выше 8.10.x.

Требования к правам пользователя Aria Operations Manager

Сервисная учетная запись для Aria Operations должна иметь разрешение только на чтение (read-only) с выбранной опцией распространения на дочерние объекты (Propagate to children) в vCenter Server.

Руководство по установке

Инструкции по установке и развертыванию:

• Скачайте файл "vKaan - vSphere Health Check.zip" и извлеките его в папку.
• Установите файл "vKaan - vSphere Health Check-1.x.x.x.pak" через меню Data Sources > Integration > Repository.
• Импортируйте файл "vKaan - Cluster Configuration Views.xml" из меню Environment > Views.
• Добавьте ваш vCenter Server в vKaan через меню Data Sources > Integrations > Repository.
• После того как vKaan MP завершит сбор данных, вы сможете открыть представление "vKaan - Cluster Configuration Summary Dashboard".

Скачать vKaan - vSphere Health Check можно по этой ссылке.

VMware VMmark 4.0 - это бесплатный кластерный бенчмарк, который измеряет производительность и масштабируемость виртуальных корпоративных сред.

VMmark 4 продолжает использовать дизайн и архитектуру предыдущих версий VMmark, предоставляя улучшенную автоматизацию и отчетность. Он использует модульный дизайн нагрузки с разнородными приложениями, включающий обновленные версии нескольких нагрузок из VMmark 3, также в нем появились и новые современные приложения, которые более точно соответствуют современным корпоративным виртуальным средам.

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

• Позволяет точно и повторяемо оценивать производительность виртуальных датацентров на основе vSphere.
• Использует разнообразные традиционные, устаревшие и современные нагрузки приложений в разнородном модульном подходе.
• Облегчает анализ и сравнение изменений в оборудовании, программном обеспечении и конфигурациях виртуальных сред VMware.
• Уровни создаваемой нагрузки теперь значительно выше, чем в предыдущих версиях VMmark, чтобы лучше отражать современные реалии.

Обновления удобства использования VMmark 4:

• Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
• Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
• Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
• Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
• Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
• Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
• Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
• Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

• NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
• SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
• DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
• Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
• Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

• vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
• Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
• Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
• Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

Скачать VMware VMmark 4.0 можно по этой ссылке.

Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.

Интересный пост от John Nicholson о размещении сервера VMware vCenter в растянутом кластере vSAN Stretched Cluster. В идеальном мире у вас есть управляющий кластер, который содержит ваш сервер vCenter, а вы управляете каждым кластером из него. Но, к сожалению, в реальном мире всё сложнее:

• Необходимо тоже как-то управлять управляющим кластером.
• Иногда нужно, чтобы кластер был полностью автономным.

Можно ли запустить сервер vCenter на управляемом им кластере?

Надо сказать, что всегда полностью поддерживался запуск сервера vCenter на управляемом им кластере. Высокая доступность (HA) в этом случае всё равно будет работать. Если вам нужно более подробно изучить этот вопрос, этот короткий видеоролик ответит на ваш вопрос.

Итак, какой лучший совет при размещении vCenter?

Используйте ephemeral port groups для всех управляющих сетей. Это предотвратит проблемы chicken-egg с виртуальными распределенными коммутаторами (vDS), которые раздражают, но с которыми можно справиться.

Автор предпочитает использовать правила DRS типа "SHOULD", чтобы vCenter "как правило" находился на узле с наименьшим номером или IP-адресом в кластере. Это полезно в ситуации, когда vCenter работает с ошибками и службы управления не запускаются, так как это упрощает поиск узла, на котором он работает. Обязательно избегайте использования правил "MUST" для этого, так как это не позволит vCenter запуститься в другом месте в случае сбоя данного узла.

А как насчет распределенного кластера? Например, у вас есть отдельный хост для запуска сервера Witness, стоит ли размещать его там?

Вот такое делать не рекомендуется. Всегда предпочтительнее запускать сервер vCenter там, где он будет защищен с помощью высокой доступности (HA), и ему не потребуется выключение для обновления хоста. Растянутые кластеры vSAN всегда поддерживают операции active/active, и многие клиенты часто настраивают их так, чтобы большинство рабочих нагрузок выполнялись в предпочтительном датацентре (preferred site). Если вы используете эту конфигурацию, рекомендуется запускать сервер vCenter во вторичном (secondary) местоположении по нескольким причинам:

• В случае сбоя основного сайта, вы не останетесь «операционно слепым», поскольку HA со стороны vCenter будет активирована и восстановит рабочие нагрузки. Это снизит любые операционные простои, которые могли бы произойти в течение нескольких минут, пока сервер vCenter запустится на резервном узле основного сайта.
• Он будет действовать как указатель на состояние здоровья вторичного датацентра. В целом полезно иметь какую-то рабочую нагрузку на вторичном сайте, чтобы понимать, как будут работать эти хосты, даже если это будет относительно легкая нагрузка.

Многие администраторы часто добавляют новые хосты ESXi, но довольно редко обсуждается вопрос о том, как правильно выводить из эксплуатации хост VMware ESXi. Об этом интересную статью написал Stephen Wagner.

Многих может удивить, что нельзя просто выключить хост ESXi и удалить его из окружения сервера vCenter, так как необходимо выполнить ряд шагов заранее, чтобы обеспечить успешный вывод из эксплуатации (decomission). Правильное списание хоста ESXi предотвращает появление изолированных объектов в базе данных vCenter, которые иногда могут вызывать проблемы в будущем.

Итак, процесс: как списать хост ESXi

Предполагается, что вы уже перенесли все ваши виртуальные машины, шаблоны и файлы с хоста, и он не содержит данных, которые требуют резервного копирования или миграции. Если вы этого не сделали - проверьте все еще раз, на хосте могут оказаться, например, кастомные скрипты, которые вы не сохраняли в другом месте.

Вкратце процесс выглядит так:

• Перевод ESXi в режим обслуживания (Maintenance Mode)
• Удаление хоста из распределенного коммутатора vSphere Distributed Switch (vDS)
• Отключение и размонтирование томов iSCSI LUN
• Перемещение хоста из кластера в датацентр как отдельного хоста
• Удаление хоста из инвентаря (Inventory)
• Выполнение расширенных процедур

Вход в режим обслуживания

Мы переходим в режим обслуживания, чтобы убедиться, что на хосте не запущены виртуальные машины. Вы можете просто щелкнуть правой кнопкой мыши по хосту и войти в режим обслуживания (Enter Maintenance Mode):

Если хост ESXi входит в состав кластера VMware vSAN, то вам будут предложены опции того, что нужно сделать с данными на нем хранящимися:

Удаление хоста из окружения vSphere Distributed Switch (vDS)

Необходимо аккуратно удалить хост из любых распределенных коммутаторов vDS (VMware Distributed Switches) перед удалением хоста из сервера vCenter.

Вы можете создать стандартный vSwitch и мигрировать адаптеры vmk (VMware Kernel) с vDS на обычный vSwitch, чтобы поддерживать связь с сервером vCenter и другими сетями.

Обратите внимание, что если вы используете коммутаторы vDS для подключений iSCSI, необходимо заранее разработать план по этому поводу, либо размонтировать/отключить iSCSI LUN на vDS перед удалением хоста, либо аккуратно мигрировать адаптеры vmk на стандартный vSwitch, используя MPIO для предотвращения потери связи во время выполнения процесса.

Размонтирование и отключение iSCSI LUN

Теперь вы можете приступить к размонтированию и отключению iSCSI LUN с выбранного хоста ESXi:

• Размонтируйте тома iSCSI LUN с хоста
• Отключите эти iSCSI LUN

Нужно размонтировать LUN только на выводимом из эксплуатации хосте, а затем отключить LUN также только на списываемом хосте.

Перемещение хоста из кластера в датацентр как отдельного хоста

Хотя это может быть необязательным, это полезно, чтобы позволить службам кластера vSphere (HA/DRS) адаптироваться к удалению хоста, а также обработать реконфигурацию агента HA на хосте ESXi. Для этого вы можете просто переместить хост из кластера на уровень родительского дата-центра.

Удаление хоста из инвентаря

После перемещения хоста и прошествия некоторого времени, вы теперь можете приступить к его удалению из Inventory. Пока хост включен и все еще подключен к vCenter, щелкните правой кнопкой мыши по хосту и выберите «Remove from Inventory». Это позволит аккуратно удалить объекты из vCenter, а также удалить агент HA с хоста ESXi.

Повторное использование хоста

Начиная с этого момента, вы можете войти напрямую на хост ESXi с помощью локального пароля root и выключить хост. Сделать этого можно также с помощью обновленного VMware Host Client.